🏗️🔧:stop reading a step's input as an action - #912
Conversation
Found reviewing the port of this file into the portal, where it landed as 4ec195f. The visitor matched every `uses` key in the document, and `with:` and `env:` hold names the action being called chose. A step passing an input that happens to be called `uses` was read as naming an action, so an ordinary workflow failed a check it had no way to satisfy. Those two mappings are skipped now. The opposite was also suggested there -- narrowing the walk to `jobs.<id>.uses` and `jobs.<id>.steps[*].uses`, the two paths GitHub executes from. That would open a hole rather than close one. A step written once under a YAML anchor and aliased into a job is a scalar only where the anchor is defined, which is nowhere near either path, and the alias itself is not a scalar for the visitor to read. Checked: an unpinned action defined under a top-level `x-defs:` anchor and aliased into a step is caught today, at the line the anchor is written on, and is missed entirely if the walk is narrowed. So the walk stays broad and only the two input mappings are excluded. Checked against one fixture carrying all five cases: inputs called `uses` under `with:` and under `env:` are ignored, a tag-pinned step and an anchored unpinned action are both reported, and a digest-pinned `docker://` passes. The five workflows here still pass. The file is byte-identical to the portal's again with this, but for the package name in its import. Signed-off-by: Derek Lewis <DerekNonGeneric@inf.is> Assisted-by: Claude-Code:claude-opus-5
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 8 included reviews per hour; 1 remains after this review. 📝 WalkthroughWalkthroughThe workflow verifier now receives YAML ancestor paths and excludes ChangesWorkflow action reference filtering
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to Workflow verification now ignores input and environment values named 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Found while reviewing the port of this file into the portal, where the fix landed as
4ec195f.The visitor matched every
useskey in the document, andwith:andenv:hold names the action being called chose. A step passing an input that happens to be calleduseswas read as naming an action, so an ordinary workflow failed a check it had no way to satisfy. Those two mappings are skipped now.Why not narrow the walk instead
The review that found this suggested restricting the visitor to
jobs.<job_id>.usesandjobs.<job_id>.steps[*].uses— the two paths GitHub actually executes from. That would open a hole rather than close one.A step written once under a YAML anchor and aliased into a job is a scalar only where the anchor is defined, which is nowhere near either path; the alias itself is not a scalar for the visitor to read. Tested:
The broad walk reports this at the anchor line. Narrowed, it is missed entirely. So the walk stays broad and only the two input mappings are excluded.
How it was checked
One fixture carrying all five cases:
usesinput underwith:usesinput underenv:actions/setup-node@v4hidden/action@maindocker://alpine@sha256:…The five real workflows here still pass;
verify.tsclean; no new failures inverify.all. With this the file is byte-identical to the portal's, but for the package name in its import.Summary by CodeRabbit
usesvalues inside action inputs or environment variables as action references.