Fix this repository's own install, and find the caller by content - #135
Merged
Conversation
v0.3.0 requires appName and changed the handle, and I updated the template without updating this repository's own install. Its config had no appName, so preflight failed, and its caller still triggered on the old prefix, so no comment could fire. The repository the agent actually works in was broken by the release. The drift check then found a flaw in itself. It looked for the caller at .github/workflows/simplycubed.yml, which is what init writes, but here that name belongs to the reusable workflow and the caller is simplycubed-caller.yml. It now finds the caller by the reusable-workflow call it makes, so a renamed caller is checked and a same-named non-caller is ignored. Only two repositories in the org have an install: this one and corp. An earlier scan reported all fifteen, which was wrong: gh api on a 404 returns a JSON body, so --jq '.sha' yielded the string "null" and every repo looked present.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Codecov flagged five lines, all branches the rewrite introduced and nothing exercised: a subdirectory in .github/workflows, an unrelated workflow encountered before the caller, and a repository with no caller at all. The middle one was hidden by filename order. The existing test wrote the caller as simplycubed-caller.yml and the non-caller as simplycubed.yml, so the caller was found first and the loop returned before it ever skipped anything. Naming them aa- and zz- makes the skip actually happen. Each of these is a check that would otherwise error on an ordinary repository layout, and a check that errors on a normal repo is one people turn off.
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
1 participant
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.
This repository was broken by its own release
v0.3.0 requires
appName:and changed the handle. I updated the template and missed the dogfood install here:.github/simplycubed.ymlhad noappName:, sopreflightfailed with a configuration miss.github/workflows/simplycubed-caller.ymlstill triggered on/simplycubed, which the v0.3.0 parser does not recogniseSince the caller pins
@main, both were live. Anysc:gohere would have failed at preflight, and no comment command could fire at all.The drift check found a flaw in itself
Adding
appNamemadepreflightfail with:Correct alarm, wrong file. It looked for the caller at the name
initwrites, but in this repository that name belongs to the reusable workflow and the caller issimplycubed-caller.yml.It now finds the caller by the reusable-workflow call it makes, not by filename. That is more correct generally: an adopter can rename their caller, and a check keyed on the filename would either pass on the wrong file or fail on a valid install.
Tested both directions — a renamed caller that agrees passes, and a same-named non-caller is ignored.
Scope of the upgrade problem
Only two repositories in the org have an install: this one and
corp. Both are now current.My earlier scan reported all fifteen, which was wrong.
gh apion a 404 returns a JSON error body, so--jq '.sha'yielded the literal stringnull— non-empty, so every repository looked installed. Caught by the fetched files being zero bytes.