Request review and comments: Copyartifact 2.0
Ikedam
I'm developing a big change for copyartifact plugin, which I plan to release as copyartifact-2.0.
I want reviews and comments for this change.
https://wiki.jenkins-ci.org/display/JENKINS/Preview+for+Copy+Artifact+2.0
https://github.com/jenkinsci/copyartifact-plugin/pull/71
https://github.com/ikedam/copyartifact-plugin/tree/feature/JENKINS-24892_CopyArtifact2.0
I plan to start beta-testing as git-plugin did (https://wiki.jenkins-ci.org/display/JENKINS/Git+plugin+2.0+beta+testing),
after adding more texts (javadocs and helps) and unit tests for new features.
Regards,
ikedam
Richard Bywater
Had a brief peek at the Wiki page and looks interesting. One question I have is whether it is planned to support the multi branch plugin?
Richard
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/f818a86d-3cf7-40c7-8982-9744c7e269be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
domi
Ikedam
I don't know about multi-branch plugin and don't plan any special features for that.
Do you mean you have problems integrating copyartifact and multi-branch?
Please create a JIRA issue for that.
ikedam
Jesse Glick
> https://wiki.jenkins-ci.org/display/JENKINS/Preview+for+Copy+Artifact+2.0
Very nice. Some technical comments:
> VirtualFile (ArtifactManager) doesn't support listing files with ant file patttens (like */.java)
Does `String[] list(String glob)` not work as advertised?
> copy artifacts from generic ArtifactManager. This doesn't preserver file modes and symbolic links (as VirtualFile doesn't provide that feature)
Not currently, but you should file a PR to let it! (Or better, just
let it create a TAR stream.)
And you should not allow users to specifically request a copier for
`StandardArtifactManager`, since we expect that such features would be
added to the API in the future. Instead, there should be one
`ArtifactManager` copier, which *currently* will need to check for
`instanceof StandardArtifactManager` and specially handle file
modes/links/etc., but which will in the future call standard API
methods.
> TriggeringBuildSelector may cause performance issues.
> It tracks and lists all upstream builds to enumerate upstream builds.
> Generator pattern should be useful for this case but I couldn't find common and reliable implementation for that.
Plenty of Jenkins code lazily enumerates builds. There is a whole
series of helper methods in `RunList`.
Ikedam
I think it can be introduced even after releasing 2.0 without breaking compatibilities.
Please let me know if you expect more features and it should be introduced at 2.0, not 2.x
(I don't know so much about integration with workflow).
ikedam
Ikedam
It works!
But doesn't support exclude patterns...
I fixed the Wiki page.
I found I confused myself a little.
1. I tried to migrate FilePath to VirtualFile preserving the behavior of copyartifact.
2. I found it's impossible to preserve the behavior as VirtualFile doesn't provide features compatible to FilePath (file modes, symlinks, exclude patterns).
3. I decided to introduce CopyArtifactOperation and provide both coping with FilePath and coping with VirtualFile.
So I no longer need exclude patterns for VirtualFile.
I can wait for future improvements of VirtualFile.
> Instead, there should be one
> `ArtifactManager` copier, which *currently* will need to check for
> `instanceof StandardArtifactManager`
I wish I could test `instanceof FilePathVF`!
But it is private.
I agree that.
I'll switch copying for generic ArtifactManager and that for StandardArtifactManager internally,
noting limitations for generic ArtifactManagers in help texts.
> Plenty of Jenkins code lazily enumerates builds. There is a whole
> series of helper methods in `RunList`.
Thank!. I'll try that.
ikedam