Skip to content

Add cache and artifact compression level options

Arran Walker requested to merge fiveturns/gitlab-runner:compression-level into master

What does this MR do?

Adds option for setting Deflate compression level for artifacts and caches.

The compression level can be controlled with the job variables CACHE_COMPRESSION_LEVEL and ARTIFACT_COMPRESSION_LEVEL.

The level specified matches the options defined in the compress/flate package.

Level 0 (flate.NoCompression) modifies the ZIP compression method to use Store, rather than using Deflate with no compression.

Why was this MR needed?

There's been quite a few issues raised about caching/artifact archiving being slow. This MR intends to fix that by allowing users to control whether they want a larger archive with smaller compression overhead, or a smaller archive that takes longer to produce and extract.

In discussions, it's often proposed that additional archive formats/compression algorithms are implemented, however there's often reasons why this shouldn't be the case:

  • The "zip" format is more an internal thing, allowing Gitlab to browse the contents and serve files from within.

This MR only modifies the runner and the compression level used.

  • You can't please everybody. Go doesn't have a fast implementation of every format/algorithm.

By setting the compression level to zero, you can archive in "Store" only mode. This allows users to compress artifact files in whatever format they want as part of the CI process, and then wrap them into the supported artifact file format with no additional compression overhead.

Are there points in the code the reviewer needs to double check?

Does this MR meet the acceptance criteria?

  • Documentation created/updated
  • Added tests for this feature/bug
  • In case of conflicts with master - branch was rebased

What are the relevant issue numbers?

#1797 (closed) https://gitlab.com/gitlab-org/gitlab-ce/issues/33179 #1765

Status

We are currently reviewing !1640 (closed) before to review this one, check reasoning for this in !1173 (comment 238989011)

closes #4907 (closed)

Merge request reports