fix(release): pin RUNA_REF to stable runa v0.1.2#20
Merged
Conversation
The previous false-start cut of base v0.1.1 failed because Dockerfile's ARG RUNA_REF= defaults pointed at v0.1.2-rc.1, a tag that had been deleted during parking-cleanup. The container build step could not resolve the ref; the workflow failed; no GitHub Release published. Updates: - Dockerfile: both ARG RUNA_REF= occurrences (builder stage + final image label) now default to v0.1.2 (the published stable runa release, cut today). - README.md: build examples reference v0.1.1 (base) and v0.1.2 (runa) to match current component substrate. - RELEASING.md: adds a Dependencies section documenting that base depends on a published runa tag via RUNA_REF, with operator guidance for cut sequencing when updating RUNA_REF. - CHANGELOG.md: Changed entries under [Unreleased] documenting the RUNA_REF update and the new RELEASING.md operator guidance. The new RELEASING.md guidance is intended to prevent the same regression class: anyone preparing a base cut now reads (in the canonical release documentation) that RUNA_REF must point at a published runa tag, and that cutting base before runa would orphan the base tag.
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
1 participant
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.
Summary
Fix the substrate defect that caused the v0.1.1 cut to fail. Dockerfile's
ARG RUNA_REF=defaults pointed atv0.1.2-rc.1, a tag deleted during parking-cleanup. Container build step couldn't resolve the ref; workflow failed; no Release published. Cleanup of the false-start cut already done on main (commit 4e45954 reverting the chore release commit, v0.1.1 tag deleted from origin).Key changes
Dockerfile: bothARG RUNA_REF=occurrences updated tov0.1.2(the published stable runa release cut today)README.md: build examples reference current stable component tags (v0.1.1 base + v0.1.2 runa)RELEASING.md: new Dependencies section documenting that base depends on a published runa tag viaRUNA_REF, with operator guidance for cut sequencingCHANGELOG.md: Changed entries under [Unreleased] documenting both substrate updatesWhy the RELEASING.md update
The discoverability test: anyone preparing a base cut reads RELEASING.md. The Dependencies section sits right before the Pre-Release Gate, so the dependency check is captured in the canonical release procedure. Future base cuts will see (and execute) the RUNA_REF verification step before firing release-cut.
Verification
./scripts/release-check metadata: exit 0./scripts/test-release-check: passesv0.1.2-rc.1references in repoNext
Merge → re-cut base v0.1.1 → continue parking sequence (commons manifest + commons cut).