Publish gf180mcu-precheck.pdk_version image label; fail build on unresolvable labels - #45
Open
mithro wants to merge 4 commits into
Open
Publish gf180mcu-precheck.pdk_version image label; fail build on unresolvable labels#45mithro wants to merge 4 commits into
mithro wants to merge 4 commits into
Conversation
The Makefile pins the PDK as an open_pdks commit hash (ciel enable), but downstream consumers like platform.wafer.space need a human-meaningful PDK version. Resolve the pinned commit to open_pdks' VERSION file content at that commit (e.g. d658698b -> 1.0.604). Unresolvable values are fatal (non-zero exit) so callers cannot silently publish images with missing version metadata. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KMV2xQm2RP5JiTzU22U1sJ
Reads docker/metadata-action JSON output and fails if any label the build promises to publish is missing or empty. Guards against GitHub Actions expressions silently expanding to empty strings. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KMV2xQm2RP5JiTzU22U1sJ
Resolve the pinned PDK_COMMIT to a version number at build time and publish it as image labels; verify all required labels resolved to non-empty values before building. Both steps are fatal on failure. platform.wafer.space's revision-metadata fetch has been failing for every image built since the June 2026 PDK_TAG->PDK_COMMIT Makefile change: it required a PDK version from the (preferred) image label or the (removed) Makefile PDK_TAG, found neither, and discarded all metadata - leaving check status pages showing raw sha256 digests instead of version numbers. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KMV2xQm2RP5JiTzU22U1sJ
This was referenced Jul 9, 2026
resolve_pdk_version.py fetched the VERSION file from efabless/open_pdks, which has been archived since 2022 and does not carry the pinned commit on any of its own branches (it only resolved via GitHub's shared fork-network storage, which is fragile). Point at the actively-maintained fossi-foundation/open_pdks fork, where PDK_COMMIT (d658698, VERSION 1.0.604) is a real ref. Verified: resolver still returns pdk_version=1.0.604 for the pinned commit. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LtHCsJ77CY3f6N8FcTELW9
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.
Why
platform.wafer.space's revision-metadata fetch has been failing for every image built since 2026-06-03, when adfc552 ("feat: use open_pdks") replaced
PDK_TAG ?= 1.6.6withPDK_COMMIT ?= <open_pdks sha1>in the Makefile. The platform requires a PDK version from either thegf180mcu-precheck.pdk_versionimage label (never published) or the Makefile'sPDK_TAG(removed), finds neither, raisesValueError, and discards all fetched metadata — so its check-status pages show rawsha256:...digests instead of version numbers, and it re-fetches every 5 minutes forever.What
scripts/resolve_pdk_version.py— resolves the pinnedPDK_COMMITto open_pdks'VERSIONfile content at that commit (currentlyd658698b→1.0.604). Any failure (missingPDK_COMMIT, unfetchable commit, non-version content) exits non-zero.scripts/check_image_labels.py— validates the final label set fromdocker/metadata-actionbefore the build: all required labels (gf180mcu-precheck.pdk_version,gf180mcu-precheck.pdk_commit, OCI created/revision/version) must be non-empty. Catches Actions expressions silently expanding to""(typo'd step id, renamed output).docker-publish.yml— runs the resolver, feeds both new labels throughmetadata-action, and gates the build on the completeness check. Unresolvable label values now fail the build instead of silently publishing an unlabeled image.Verification
pdk_commit=d658698bd8bcf4e05fc7b5991a701247ba0d744c,pdk_version=1.0.604(matches open_pdks' "chore: bump version" commit for 1.0.604).Both scripts are stdlib-only Python (no uv/pip setup needed in the workflow).
Note: label values are:
gf180mcu-precheck.pdk_version=1.0.604(open_pdks version scheme — differs from the old wafer-space/gf180mcu1.6.xtags, as the PDK source itself changed) plusgf180mcu-precheck.pdk_commitfor exact traceability.🤖 Generated with Claude Code
https://claude.ai/code/session_01KMV2xQm2RP5JiTzU22U1sJ