Repository navigation
fix(k8s_apps): build release-workflow images with OUTPUT_OCI - #6282
Merged
Merged
Conversation
The release-resource workflow's image jobs (_build_image_job and _build_release_image_job) were missing the OUTPUT_OCI fix that #5722 added to the legacy path. Images built FROM mitodl/ol-python-base carry zstd layers from the DHI base; oci-build-task's default Docker-format tarball labels them gzip, so the registry-image put's implicit get fails with "gzip: invalid header". This broke micromasters' first build after #6248 and learn-ai's release image build. Set OUTPUT_OCI and push the image/image layout directory, keeping the tarball only when uploading Sentry source maps, as the legacy path does.
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
The Sentry tarball exception lacks regression coverage.
1 open finding
What changed in this PR
Adds OCI output support to release-resource image builds, preserving zstd layer metadata.
Changes:
- Enables
OUTPUT_OCIand pushes OCI layout directories. - Retains tarball output for Sentry source-map builds.
- Adds regression coverage for standard image builds.
| File | Description |
|---|---|
pipeline.py |
Configures OCI output and matching registry paths. |
test_k8s_apps_output_oci.py |
Tests OCI parameters and image paths. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
A release image build that uploads Sentry source maps must skip OUTPUT_OCI and push image/image.tar, since the upload reads the unpacked rootfs.
blarghmatey
approved these changes
Oct 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What are the relevant tickets?
N/A. Follow-up to #6248, which broke
build-micromasters-image-from-master.Description (What does it do?)
OUTPUT_OCI=trueon the release-resource workflow's image builds (_build_image_joband_build_release_image_job), matching what fix(ol-python-base): re-rebase onto DHI via OUTPUT_OCI, not mirroring #5722 did for the legacy path (Switch hardened-base app builds to OUTPUT_OCI instead of mirroring, to preserve DHI signed provenance #5714).image/imageOCI layout directory instead ofimage/image.tar.Without this, any app on the release-resource workflow that builds
FROM mitodl/ol-python-basepushes its DHI zstd layers labeled as gzip. The put step's implicit get then fails:Currently failing this way:
Implementation details
In the manifest that build #2 pushed, every layer is typed
application/vnd.docker.image.rootfs.diff.tar.gzip. But the first five blobs start with the zstd magic number28b52ffd, not gzip's1f8b. They're the same blobs thatmitodl/ol-python-base:3.11correctly declares asapplication/vnd.oci.image.layer.v1.tar+zstd.oci-build-task's default Docker-format tarball has no zstd media type, so those layers keep their bytes but get relabeled as gzip.
OUTPUT_OCIkeeps the original labels. With it set, oci-build-task writes an OCI layout directory atimage/image, so the putimageparam changes to match.ol-analytics-apiis also on this workflow. It doesn't build fromol-python-base, and its builds have been passing; with this change it picks up OCI output too.How can this be tested?
tests/ol_concourse/test_k8s_apps_output_oci.pychecks that micromasters' main and release image jobs setOUTPUT_OCIand pushimage/image. Both tests fail onmain(KeyError: 'OUTPUT_OCI') and pass on this branch. All 414 tests intests/ol_concoursepass.micromasterspipeline with the deployedmicromasters-pipeline(fly get-pipeline). Only the two build jobs change: each gainsOUTPUT_OCI: "true", and its puts switch fromimage/image.tartoimage/image. The set of jobs is identical.k8s-apps-metare-sets the pipelines, re-runbuild-micromasters-image-from-masterandbuild-learn-ai-release-image. Both should get past the put step's implicit get.