Use human-readable signed image and bundle release tags #64
No reviewers
Labels
No labels
app-migration
bug
ci-cd
cluster
Documentation
duplicate
enhancement
gpu
invalid
networking
question
security
Storage
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Homelab/workflows!64
Loading…
Reference in a new issue
No description provided.
Delete branch "kiyi/readable-release-tags"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Owner request
Every future release must identify its component and readable version, for example
gitchauth-theme-v1, and deployment must accept that tag.Changes
Validation
73 source/mocked tests passed across release tags, container publication, trusted images, delivery, promotion, malware reuse, release downloads and Forgejo contracts;
git diff --checkpassed. No local Docker or cluster tests. Hosted publication/deployment remain unverified.Adoption
Proposed for v1.24.0. After review/merge, the operator publishes that unused version with the normal release Action, then merges paired caller pins. Upgrade publishers and deploy/evidence consumers together. Older caller mitigation schemas require their own stable-finding migration; this change does not renew risk acceptance.
Request changes: the bundle build step does not export RUN_ID, but delivery.build now reads os.environ["RUN_ID"] when writing its schema 2 receipt. This breaks every normal bundle publication before a receipt or release is created, including when an explicit release_tag is supplied. I reproduced the production build function with its existing mocked package fixture and workflow-equivalent environment: it created the bundle archive, then raised KeyError("RUN_ID") and wrote no receipt. Add RUN_ID: ${{ forgejo.run_id }} to the "Scan every image and build UDS bundle" step and cover that workflow-to-helper contract.
All 222 local tests passed (one skipped), diff and YAML parsing passed, and three exact-head hosted checks passed; those tests inject RUN_ID directly and thus miss the workflow wiring. No publication or deployment was run.
@ -185,2 +186,3 @@with stage('Hash bundle artifacts and write receipt'):receipt = {'schema': 1, 'repository': repository, 'source_sha': sha,receipt = {'schema': 2, 'repository': repository, 'source_sha': sha,'release_tag': choose(app['name'] + '-bundle', app['version'], os.environ['RUN_ID'],Blocking: .forgejo/workflows/build-bundle.yml exports RUN_ID to the owner guard and publish steps, but not to its "Scan every image and build UDS bundle" step. This new os.environ["RUN_ID"] lookup fails with KeyError after the archive is built, before receipt generation, for both default and explicit release_tag inputs. I reproduced it with the test fixture and the step's environment. Export RUN_ID: ${{ forgejo.run_id }} to the build step and add a workflow contract test.
Fixed in 165b5fd. The bundle build step now exports
RUN_ID: ${{ forgejo.run_id }}alongsideRELEASE_TAGandLIBRARY_SHA.Added a workflow contract check for these receipt inputs and changed the existing mocked bundle build test to derive its environment from the actual workflow YAML, clearing inherited variables. It exercises both the automatic tag and an explicit
example-bundle-v1, verifies schema 2 receipt creation and keeps the artifact-tampering check. Before the fix, both cases reproducedKeyError("RUN_ID"); after the fix, all 74 targeted source/mocked tests passed, including delivery and Forgejo contracts.git diff --checkpassed. Hosted checks for this new commit remain pending; no publication/deployment was run.Approved at
165b5fd. The bundle build step now exports forgejo.run_id as RUN_ID to the actual delivery.py build invocation, and the new workflow-contract test plus mocked production build exercise both the default and explicit readable tags through receipt generation. The previously reproduced KeyError("RUN_ID") is fixed. All 223 local tests passed (one skipped), Python compilation and diff check passed, and all three exact-head hosted checks succeeded. The hosted security decision passed with zero scanner errors. This is source/workflow verification only; no real release publication or deployment was dispatched.