Does running zstd compression output not result in a gzip recomputation just because s3 cache only supports gzip?

[whitehatbuds]

From my tests, it seems like it doesn't run it again. I was thinking running a zstd compression output, but a s3 export cache with gzip would run two compressions instead of 1, making it slower than just (gzip output, gzip s3 cache)

[theboringhumane]

An existing blob can be reused, so two exporter settings don't necessarily mean two compression passes. In v0.33.0, blob creation returns early when a blob already exists; forcing the requested compression is a separate step. That could explain your result, though the exact command and cache state matter.

There's also a recent change relevant to the “S3 only supports gzip” part: #7121 merged on September 23. The S3 format can store other compression types; the exporter was ignoring compression, compression-level and force-compression and returning the default configuration. That PR makes it honor those attributes.

The latest release, v0.33.0, still has the old configuration, so the new options in the current README aren't available in that release. A release containing the fix will let you request compression=zstd for S3 too. Whether that is faster for your build needs a measurement; this source check doesn't establish the timing result.