-
New Feature
-
Resolution: Fixed
-
Major
-
None
Currently artifact archiving follows a fixed model: artifacts are defined in ArtifactArchiver (or MavenArtifactArchiver) configuration; they are copied from slave to master using FilePath.copyRecursiveTo; they are stored in ${Run.rootDir}/archive; and they are served by browsing this directory in master.
This system has obvious scalability limitations: channel transfer is not particularly efficient; and storing enormous files in the builds directory can cause disk overruns.
The CloudBees Fast Archiver plugin tries to address the transfer speed issue by using a better algorithm. This helps, but the implementation (replacing the ArtifactArchiver build step) is very awkward, and cannot be made to work properly with Maven projects, fingerprints, etc.
Some installations may anyway not need to copy files at all. The master and slave might share a common network filesystem, or might have a way of efficiently transferring file references (e.g. ZFS send).
Finally, there should be the option to store artifacts in a better way: on a big slow drive, in a compressed archive, etc.
To handle all these requirements we need an extension point that encompasses both transfer and storage of artifacts for each build.
- depends on
-
JENKINS-19752 Download build artifacts as zip generates a corrupted file
- Resolved
-
JENKINS-20663 file name encoding broken in zip archives
- Resolved
-
JENKINS-19947 Missing base directory in ZIP from .../artifact/dir/subdir/*zip*/subdir.zip
- Resolved
- is blocking
-
JENKINS-6229 Compress archived artifacts
- Resolved
- is related to
-
JENKINS-7813 Archiving artifacts very slow
- Resolved
-
JENKINS-10502 Add an option to make archiving the artifacts non-fatal if they don't exist
- Resolved
-
JENKINS-21958 ArtifactManager introduces regression with publishing symbolic links.
- Resolved
- relates to
-
JENKINS-49635 Permit VirtualFile to serve external file contents
- Resolved