Use zstd compression?

Open Beginner friendly
#253 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
84/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
docker, github-actions

Research direction

Start in .github/workflows/docker.yml at the docker/build-push-action step that builds and pushes each version-architecture image. Review the existing image output settings, then validate a published image manifest and downstream pull behavior. Done means the relevant layers are zstd-compressed and the workflow still publishes all matrix images successfully.

Written by the indexing model from the issue text.

Description

Priority: Wishlist
Problem

Pulling ghcr.io/elementary/flatpak-platform/runtime:8 (and presumably the other version tags) in downstream CI consistently takes ~2m20s–2m30s, which dominates the total build job time (often >85% of it) for small consumer apps. Example from a real run building a small Vala app (checkout + full meson build + tests + flatpak bundle takes ~17s once the image is available):

I inspected the published manifest for the 8 tag:

docker manifest inspect ghcr.io/elementary/flatpak-platform/runtime@sha256:84eabe1d28f1a8eda9e771b153759292c6b83bdde2d2b4f1f4eec22a0f605130

Two layers dominate the image, together ~2.3GB compressed, dwarfing the other ten layers combined (~720MB):

digest (short) compressed size media type
93a4a1aea6e7 1,268,644,102 bytes (1.27GB) application/vnd.oci.image.layer.v1.tar+gzip
192c972a8866 1,083,344,025 bytes (1.08GB) application/vnd.oci.image.layer.v1.tar+gzip

These correspond to the RUN flatpak install -y --noninteractive appcenter io.elementary.Platform/... io.elementary.Sdk/... step in docker.yml — i.e. an OSTree deployment (tens of thousands of small files) baked into a couple of plain tar layers.

Cross-referencing the CI logs: the network download of every layer finishes in ~15s (bandwidth isn't the bottleneck), but extraction (decompress + untar to disk) of just these two layers takes the other ~2 minutes.

Proposal

All layers currently use tar+gzip. Switching the pushed image to zstd-compressed layers should meaningfully cut this, since zstd decompresses roughly 2-5x faster than gzip at an equal or better compression ratio, and it's natively supported by the docker/build-push-action/buildx pipeline already used in docker.yml, e.g.:

- name: Build & push the ${{ matrix.version }}-${{ matrix.arch }} image
  uses: docker/build-push-action@v7.3.0
  with:
    ...
    outputs: type=image,compression=zstd,compression-level=19,force-compression=true

This doesn't change anything about what's in the image (no compatibility risk for consumers), just how it's packed — so it seems low-risk relative to the payoff for every project building against this image.

Prior Art (Optional)

None found in this repo's issue tracker; closest related work is #234 (rebasing the base image to cut bloat) and #236 (fallout from that).

Dominant language
Meson
Stars
57
Forks
11
Avg merge
6h 11m
Merged PRs (30d)
7

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from elementary/flatpak-platform

All issues in elementary/flatpak-platform

Similar issues

More Build System issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.