Repository navigation
ci(release): run the changeset check with its own revision's tools - #51
Merged
Merged
Conversation
…sion
changeset-check.yml built the check from tools-ref (default main) without
the dev shell, and with devshell: true ran changeset-management from the
caller's dev shell, so the revision the caller's flake.lock pinned ran instead
of the one the caller's uses: resolved to. It now builds
github:${job.workflow_repository}/${job.workflow_sha}#release-tools with
release.yml's step and runs that binary in both modes, resolved through
realpath because the caller's sandbox binds only the store paths its command
resolves to.
tools-ref is accepted and ignored; the README says when it can go.
The e2e runs the changeset-check job both ways against a caller whose dev
shell pins an older revision, evaluating the steps' if: conditions, with a
sandbox stub that refuses an unresolved command path like bwrap does.
The README now says both workflows ignore the caller's flake.lock pin, and that devshell: false needs Nix on a self-hosted runner too, because it builds the check binary with Nix. The tools-ref description no longer points at the README, and the README keeps only when tools-ref can be removed. world.job takes its workflow and inputs as a named JobOptions object, and the two changeset-check phases come from one table so their step lists cannot drift apart.
Contributor
There was a problem hiding this comment.
Verified: changeset-check builds release-tools from github:${job.workflow_repository}/${job.workflow_sha} (same :? mechanism as #42), realpath for the sandbox bind; e2e fails on main 21fe619 (caller-lock 0449f15 tool ran) and passes on branch; real flake build exit 0; hosted Changeset run built the PR merge commit; fresh correctness review approve; CI 5/5 on 326bd5c; hunt grep clean.
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.
Summary
The reusable changeset check now runs
changeset-managementbuilt from the workflow revision the caller'suses:resolved to, the wayrelease.ymldoes since #42. Before, a caller withdevshell: trueran the copy its ownflake.lockpinned, and a caller without it ran a fresh pnpm build oftools-ref(defaultmain).Both modes now use
release.yml's step, which buildsgithub:${{ job.workflow_repository }}/${{ job.workflow_sha }}#release-toolswith the:?guards on empty context values. The check runs that binary by its resolved store path:Decisions a reviewer should check
realpathis required. The caller's bubblewrap sandbox binds the store root of the command's resolved path (nix/sandbox/sandbox.sh:192) and nothing for the link itself.release-toolsis asymlinkJoin, so the unresolved path fails inside the sandbox withbwrap: execvp …-release-tools/bin/changeset-management: No such file or directory. The workflow can't rely on a sandbox fix, because each caller runs the sandbox from its own pinned revision of this repository.tools-refis accepted and ignored. stryker-js-effect still passestools-ref: main, and removing a declared input fails the callers that pass it. The README says to drop it from callers first. This repository'schangeset.ymlno longer passes it.devshell: falsenow needs Nix as well. Hosted runners get it fromcachix/install-nix-action, and a self-hosted runner has to provide it. The README says so.Test
world.job(name, { workflow, inputs })in the e2e harness now runs a job from either reusable workflow. The harness also:if:;inputs.*, including||defaults;The
require-intentjob runs twice against a caller whose dev shell pinschangeset-managementat an older revision, once withdevshell: trueand once withdevshell: false. Each run asserts the exact steps that ran and that the check passed naming@e2e/alpha.Results of
pnpm --filter @systemfsoftware/e2e test:Tests 1 passed (1)changeset-check.ymlchangeset-management at 0449f15b2db9602a1dfe58bee2598adca2a726ed, the revision the caller's flake.lock pins, ran instead of the workflow's: check 2c034a1…realpathbwrap: execvp /tmp/workflow-release-tools/bin/changeset-management: No such file or directory (…)Real build and real sandbox
In a clean shell (
env -i, Nix profile only), the build exitsEXIT=0:That binary, run inside stryker-js-effect's own dev shell and sandbox (main 7373776d, after
nix develop --command pnpm run bootstrap):This PR's own Changeset run covers the hosted
devshell: truepath:changeset.ymlcalls the workflow onubuntu-latest, and for a localuses:thejob.workflow_shais this PR's commit.Not covered
README.mdalso changes in fix(version): version a pnpm workspace whose root manifest has no version #28. This PR isn't stacked on fix(version): version a pnpm workspace whose root manifest has no version #28.Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.