Repository navigation
ci: open installed Home, sign up and see the update in System on every PR (#89) - #240
Merged
Merged
Conversation
andersalm
force-pushed
the
ci/89-installed-home-every-pr
branch
2 times, most recently
from
October 5, 2026 23:16
6b3d746 to
7c9ddc6
Compare
…y PR (#89) The Mac CI fixture now installs home-gui and System with Home, lists custody-provider outside the Home profile like the release does, starts Home without a TTY, creates the first account through the sign-up page, waits for System to say 'Home is up to date', publishes the next version and waits for System to show it. The dispatch-only macos-cli-update-fixture job and its policy pins are removed.
…t after restart (#89) The fixture's signed releases now carry their source, which Home's System check requires; without it System never reported 'up to date'. Each release also carries the change note 'Fixture <publication>' so the journey can tell the tampered offer from the real next version.
…nings after the System update (#89) alpha.6: the updated Runtime refused the installed protected-content providers while System said 'up to date'. The journey records provider warnings from the Home start before and after the update; a separate step requires no new ones and is expected to fail until the provider fix lands.
andersalm
force-pushed
the
ci/89-installed-home-every-pr
branch
from
October 6, 2026 01:21
7c9ddc6 to
b64a830
Compare
…rsion; no wording pins
…Home process and generation
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
No CI job opened Home after a real install, so 0.8.0-alpha.3 shipped a Home that could not open (#238). This PR adds that check to
source-home-macos, which already runs on every PR.What the job now does, after it installs the signed CI fixture into a fresh HOME:
elastos home --browserwithout a TTY (a stand-inopenis on PATH) and checks that GET /home/ returns 200 and the installed pagescripts/home-passkey-virtual-auth-smoke.mjs)continue-on-error: true. The provider fix is fix(runtime): accept compatible providers across release versions (#110) #245. After fix(runtime): accept compatible providers across release versions (#110) #245 merges,continue-on-erroris dropped before this PR merges.The fixture now also ships the already built home-gui and System capsules and the protected-content protect and decrypt providers in its signed setup set. No new build. Its signed releases now carry
source(Home's System check requires it) and a change note "Fixture ", so the journey can tell the tampered offer from the real one.The refused fixture comes before the real update. After the update, every fixture carries the installed version, so none of them would be offered.
Why this job fails on develop before #238: the fixture's signed components.json now lists custody-provider the way the release does: pinned, outside the Home profile, and never installed. Before #238, installed-release admission required every native provider binary to be present.
elastos hometherefore stopped with "Installed release inputs require repair" and never reached readiness, so the step fails at "installed Home did not reach controller readiness". After #238, an absent provider outside the profile is skipped, and Home starts.Removed: the dispatch-only
macos-cli-update-fixturejob, its workflow inputs, and its pins inscripts/ci-release-policy-test.py. The runner/check-name/releaseneeds:pin and the pin that keeps the Mac refusal steps unconditional stay, updated for this job. Linux installs no release fixture, so it is unchanged.This job proves an installed Home with a disposable CI signing key, not a real signed release. Real signed-release proof now comes from the release workflow (#241) and from the operator's installed journey on each canary, not from CI.
Added CI time: about 10 s to install the Playwright headless shell, plus the browser journey (sign-up, two approvals, two Home restarts).
Net lines: +319 −292 = +27. The line count goes up because the full update, refusal and reconnect journey replaces a dispatch-only job that never ran on PRs.
Local checks:
scripts/update-hop-compare-test.py(111 OK),scripts/ci-release-policy-test.py(16 OK),node --checkon the smoke, YAML parse. The live journey runs only on the hosted Mac (port 8090), so this PR's CI run is the proof.