fix(ci): flag a refresh with an issue, not a pull request - #14
Conversation
The weekly refresh has been failing at the last step: GitHub Actions is not permitted to create or approve pull requests The organization disallows it, which overrides the repository setting, so `gh pr create` cannot work here no matter what the workflow asks for in its permissions block. That org policy is worth keeping. Everything before that step was fine. The branch pushes, so the failure is only that nobody gets told. Worse, it does not self-heal: every Monday it force-pushes over the branch, finds no pull request, fails again, and the drift piles up somewhere nobody looks. Issues are not covered by the policy. So push the branch as before and open an issue linking to the compare view, where opening the pull request is one click. A human was always going to review the diff, and the issue says what moved and reminds whoever reads it that the website needs its own sync afterwards. One issue per outstanding refresh: a second run comments on the open one instead of filing a duplicate.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1b4d99d260
ℹ️ 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".
| existing="$(gh issue list --state open --limit 100 --json number,title \ | ||
| --jq '.[] | [.number, .title] | @tsv' \ | ||
| | awk -F'\t' -v t="$title" '$2 == t { print $1; exit }')" |
There was a problem hiding this comment.
Search all open issues before creating another
When the repository has more than 100 open issues and the refresh issue falls outside the fetched set, this lookup returns nothing and the workflow creates a duplicate despite the one-outstanding-issue invariant. The local gh issue list --help describes --limit as the “Maximum number of issues to fetch,” so the fixed limit does not perform an exhaustive duplicate check; filter by the exact title through --search or otherwise paginate the complete result.
Useful? React with 👍 / 👎.
The weekly refresh job has been failing at its last step:
The organization disallows it, and that overrides the repository setting, so
gh pr createcannot work here whatever the workflow asks for in itspermissions block. That org policy is worth keeping: the same switch also
grants Actions the ability to approve pull requests, which is the half that
undermines required reviews.
Everything before that step was fine. The branch pushes, so the only real
failure is that nobody gets told. It also does not self-heal: every Monday it
re-derives, force-pushes over the branch, finds no pull request, and fails
again, with the drift piling up somewhere nobody looks.
Issues are not covered by the policy. So this pushes the branch exactly as
before and opens an issue linking to the compare view, where opening the pull
request is one click. A human was always going to review the diff before
merging, so this costs a click and changes nothing about the review.
The issue says what moved, and reminds whoever reads it that merging is not the
whole job: the website builds from its own committed snapshot and needs a
pnpm sync:addonsafterwards.One issue per outstanding refresh. A second run comments on the open one
instead of filing a duplicate.
What is unchanged
Trigger, derivation, the
git diff --quietguard, the branch name, theforce-push, and the files touched. A week where nothing moved still produces
nothing at all.
Verified
bash -ncompare link intact
an exact title in a synthetic test without false-matching a similar one
protect mainruleset does not interfere: it targets~DEFAULT_BRANCH, while the force-push goes tochore/refresh-derived-facts