Old builds can take up a significant amount of space on disk, even though they
often take up very little space when tarred and zipped. For example, I have a
build setup where the archived build output takes up 164MB, but can be tarred
and zipped down to 8MB. This problem is most prevalent when there are lots of
small files being archived, as with JUnit and Javadoc output.
In the mailing list, the argument against doing this is:
https://hudson.dev.java.net/servlets/ReadMsg?list=users&msgNo=10279
"In most of the situations, I don't think it makes much sense for Hudson
to do such desperate disk conservation measure. It's much cheaper to fix
the problem by throwing more HDDs at the problem, and on modern file
systems, you can have file-system level compression, too."
Throwing more HDDs is a good solution in many cases, but here it can often be a
20X win to compress the output. That means a 20X difference in the number of
HDDs required.
The problem with file-system level compression is that it will typically also
apply to the workspace folder, which can have a nontrivial impact on build
performance.
- depends on
-
JENKINS-13655 Gzipped log are not shown correctly
-
- Resolved
-
-
JENKINS-10400 gzip support for consoleText
-
- Resolved
-
- is blocking
-
JENKINS-2137 Annotation support on console output
-
- Closed
-
- is related to
-
JENKINS-6229 Compress archived artifacts
-
- Resolved
-
-
JENKINS-3268 Add support for automatic compression of builds
-
- Resolved
-
- mentioned in
-
Page Loading...
Code changed in jenkins
User: Martin Schroeder
Path:
core/src/main/java/hudson/console/AnnotatedLargeText.java
core/src/main/java/hudson/model/Run.java
core/src/main/resources/hudson/model/Run/console.jelly
http://jenkins-ci.org/commit/jenkins/346fc998b16f2021cbd6b3bb1cd1878a2b19ff5b
Log:
Enabled transparent compression support.
This only works if the "transparent GZIP support" patch has been
applied against Stapler. Otherwise, this patch will not compile
as the new "LargeText" constructor will not be found.
Additionally, the console.jelly was modified to make use of the
stream instead of the raw file, which is necessary to get the
correct uncompressed size of the file for skipping bytes.
JENKINS-2551JENKINS-10400JENKINS-13655Signed-off-by: Martin Schroeder <martin.h.schroeder@intel.com>