chore(orc): upgrade orc-standards to v8.0.1 - #329
Conversation
Re-rendered by `orc adopt`; committing the managed adapter so the render propagates through git instead of stranding as an uncommitted working-tree change (the structural cause of fleet adapter drift, #1838). Co-Authored-By: ORC (macbookprom5) <orc@orc.local> Signed-off-by: orc <orc@orc.local>
deffenda
added
the
chore:trivial
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4f494fe8a0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| # cannot see the adopter, GitHub answered 404 (its response for a hidden resource, not 403), | ||
| # and the 404 branch called that "not protected" and exited clean. Following the | ||
| # documentation silently disabled the audit. Its own secret now, or the repo's own token. | ||
| GH_TOKEN: ${{ secrets.ORC_PROTECTION_TOKEN || github.token }} |
There was a problem hiding this comment.
When an adopter follows the new instruction and creates a repo-scoped fine-grained token with only Administration read, branch-protection lookup can succeed but the audit then uses that same token for check-runs, commit statuses, PR/issue reads, and posting the evidence comment, which respectively require additional Checks, Commit statuses, Pull requests, and Issues permissions. gh help environment confirms that GH_TOKEN takes precedence over GITHUB_TOKEN, so the workflow's declared checks/issues permissions do not supplement this token; a private-repo audit will fail at lines 151/156, or fail to post the note at line 224. Document and provision all required token permissions, or use the elevated token only for the protection lookup.
Useful? React with 👍 / 👎.
Re-renders the ORC-managed adapter from orc-standards v8.0.1 (was v8.0.0).
Release notes: https://github.com/ABD-Enterprises/orc/releases/tag/v8.0.1
Generated by
orc adopt --force --with-workflows. Only ORC-managed files change.Why this one matters
v8.0.0 silently disabled the merge-override audit in this repo. It set the audit's
GH_TOKENtoORC_GUARDS_TOKEN— a secret documented as read access to the private orc repo and nothing else.GH_TOKENoutranksGITHUB_TOKENforgh, so every adopter-repo call ran with a credential that cannot see this repo. GitHub answers 404 for a hidden resource (not 403), and theNot Foundbranch classified that as "branch not protected" and exited clean.A real merge override produced no evidence note, on a green check.
The fix
ORC_PROTECTION_TOKEN, falling back togithub.token. The guards workflow keepsORC_GUARDS_TOKEN— a scope split, not a rename.GET /repos/{repo}needs only Metadata read while the protection endpoint needs Administration read, so probing visibility alone would have left the defaultgithub.tokenpath — i.e. this repo, without the secret — fail-open.What you'll notice after merging
If this repo has no
ORC_PROTECTION_TOKEN, the audit will start emitting "merge-override audit did NOT run" where v8.0.0 quietly reported clean. That is the honest state, not a new failure — the audit was never running. ProvisionORC_PROTECTION_TOKENscoped to this repo with repository-administration read to get a real one.Found by codex reviewing the v8.0.0 rollout, and again on the first cut of the fix.