Repository navigation
Prepare Python release sets with pinned candidate SDKs - #420
Merged
Merged
Conversation
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.
Python release preparation currently invokes Kit's SDK producer again and leaves the two packages' build artifacts outside the resumable candidate record. Add
release.py packages --record ... --waitto prepare both distribution sets from the frozen candidate source, using the existing build/installation/live-test workflows withdestination=none.Kit skips its SDK producer when given the generated candidate manifest and immutable manifest commit. Fetch the pinned core-selection artifact by ID and checksum, select the original Daemon run's platform SDK archive, and verify its size/checksum against that selection before passing it through the existing SDK installer and manifest/interface checks. Preserve cached SDK producer identities. Existing manual workflows retain their same-run SDK path and publishing rules.
Both packages now produce source/version/file-hash manifests. The coordinator captures run attempts, immutable artifact IDs, archive hashes, package metadata, complete file sets and per-file hashes; Kit's manifest and wheel core metadata must agree with the candidate's original SDK selection. Interrupted dispatches reconcile without duplicates, failed package jobs can be retried independently, successful siblings are reused, and accepted/expired/changed sets cannot be silently replaced. The local summary lists every distribution hash. Update the runbook and add the Python preparation/recovery guide.
This slice stops at
packages_prepared. Publication from the prepared bytes, signing/promotion handoffs, PPA availability and final destination completion remain subsequent #120 work. The current manual PyPI dispatches still rebuild; the docs state that limitation explicitly. No production tags, Release build/staging dispatches or package uploads were started to validate this PR.Validation: 78 release tests and 41 staging tests pass. New coverage includes complete package preparation/resume, lost dispatches, targeted retries, source/attempt drift, archive digest failure, expiry/replacement, actual Kit manifest-producer compatibility, missing/extra/changed distributions, metadata/SDK mismatch, and a pinned SDK fetch through the real installer. A real holder-python wheel and sdist build passed the new verifier. Core/contract boundaries, root version, YAML parsing and diff checks pass. The next actual release will exercise the full remote pinned-SDK path.
Continues #120 and #122.