Tie harness version and workflow to one release - #11
Closed
danielholanda wants to merge 1 commit into
Closed
danielholanda wants to merge 1 commit into
danielholanda wants to merge 1 commit into
Conversation
Collaborator
Author
|
PR #10 is more elegant |
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.
Make the pinned ref the harness version
The problem
The README says to pin
reusable.yml@v0.1.0, but that doesn't get you harnessv0.1.0. At that tag, every job says
uses: amd/skillscope@main, and the action'sfallback is its own ref — so you got v0.1.0's workflow running whatever
mainlooked like that morning. Nothing about the run looked wrong.
Four things could decide the version: the
versioninput,$SKILLSCOPE_VERSION,skillscope_versionin each skill'sevals.json, and the launcher's ref. None ofthem was the ref you actually pinned. That ladder existed for a "pin
@bootstrapforever, bump the version as data" story that overlaps with pinning a release tag,
and beat it.
The fix
uses: amd/skillscope@v0.1.1already downloads this whole repo at that tag into$GITHUB_ACTION_PATH. That checkout is the harness, so the launcher justinstalls from there —
uvx --from $GITHUB_ACTION_PATH skillscope <command>. Thepin is right by construction, and the default path never touches the network.
versionstays as the one override, for trying a build before pinning it.Gone with the ladder:
bootstrap/resolve_version.py,skillscope_versionandeverything reading it (
pinned_version,config.version,select --version, theplan's
versionfields), and theskill:/source:action inputs.bootstrap/launch.pymoves toaction/launch.pyat half the size.Two things stop the literal ref drifting again, since
uses:can't be anexpression: a test that fails unless
pyproject.toml,__version__, and all 19uses: amd/skillscope@…references agree, and a selftest that asserts the versionthe action reports is the one in the checkout.
Heads up
Delete
skillscope_versionfrom yourevals.jsonif you have it. The parserrejects unknown top-level keys, so leaving it fails the structural check. Nothing
replaces it — the version is the ref you pinned.
v0.1.1has to be tagged with this merge. Everything points at it, soreusable.yml@maincan't resolve the action until that tag exists.v0.1.0staysbroken;
v0.1.1is the first tag where pinning does what the README says.208 tests pass. Net 225 insertions, 719 deletions.