Repository navigation
ci(release): one key-free release workflow and operator script (#89) - #241
Merged
Merged
Conversation
Replace the unmerged canary union workflows and runbook with release-package.yml, scripts/release-publish.sh and a short section in docs/VERSIONING.md. The Linux holder check now builds the Runtime and providers from the source under test instead of a pinned 0.8.0-alpha.1 artifact.
andersalm
force-pushed
the
ci/89-one-release-workflow
branch
from
October 5, 2026 18:25
39e10f5 to
cc8ba7e
Compare
…ed-upgrade checks the run (#89)
This was referenced Oct 6, 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.
Part of #89
One release path in place of the never-merged #232 path (4,255 lines of workflows, capacity script and runbook).
What changes
.github/workflows/release-package.yml(manual run): source commit, install version N, update version N+1, andseed_package(default false). It builds the Apple silicon pair (N+1 reuses N's support) with no keys and no model inputs. The Linux seed package (Runtime N,ipfs-providerand its exact source) is built only whenseed_packageis set.scripts/release-publish.sh:prepare: downloads and checks the Mac artifact, then prepares unsigned input in an isolated data dir with Kubo from the build.policy: writes the exact signer policy with the current develop head.seed: prints the per-release import with the seed's installed Runtime. Copy 4 signed files and sums, rebuild the rest from the artifact, verify, stop, preflight, import (accepting only the known post-commit gossip error), start. It touches no source root.seed-upgrade(rare): prints the seed Runtime upgrade. Create/opt/elastosfor the service user before the stop, check and install the source, install the Runtime and provider, update the provider pin incomponents.json, verify the provider, start.docs/VERSIONING.md: new "Publishing a release" section. It replaces "Ceremony Requirements"..github/scripts/release-mac-capacity.pyand its test, run in CI next to the other release tests.canary-holder-linux.yml: no longer triggers onfix/89-canary-inputs. Per the operator decision it builds the Runtime and providers from the PR source instead of admitting the pinned 0.8.0-alpha.1 artifact (that artifact expires on 10 Oct). The frozen helper tree, observer pin and unused packaging steps are gone.scripts/holder-idle-ci.pyfollows.Checks kept: exact source and tree, on develop or an open same-repo PR head that contains develop, fresh Cargo dirs, N/N+1 version, source and support parity, artifact digests (checked again by
prepareand on the seed), and every input and signed file hash.Dropped from #232, and why:
/opt/elastos/release-source) in this reviewed workflow. Reviewing the workflow approves the root just as well, and no seed username ends up in the repo.release_publication::cargo test rerun in the seed job: CI already runs it, and the signer refuses any commit that is not on develop.tar | gzip | splitwith SHA256SUMS on both sides does the same job.Net lines: +887 / -451 = +436 against develop, and -3819 against the #232 path it replaces.
Local checks: YAML parses,
bash -npasses for the script, every workflow run block and both printed seed sequences, the capacity test passes (14 tests), pyflakes is clean, and smoke runs ofpolicy,seed,seed-upgradeandprepare(up to the git fetch) used a stubbedgh.Open risks: the release workflow has not been dispatched yet, so the first real run is its proof. The holder workflow on this PR is the proof for the holder change.