ci(repo): re-pin codex-action to v1.11, block future auto-bumps - #6538
Merged
Conversation
A Dependabot actions-major group bump (#6484) silently reverted the deliberate v1.11 pin from #6380 back to v1.12, reintroducing a job hang: AI Review run 34323125644 on PR #6535 died at ~55 minutes against a 45-minute timeout. Upstream confirms two still-open v1.12 regressions matching our exact config (drop-sudo + read-only sandbox) — openai/codex-action#151 (wrapper hangs after Codex's turn completes if a descendant keeps stdio open) and #160 (drop-sudo's v1.12 rewrite chmods /run service sockets, breaking systemd-resolved on the runner itself). Re-pin both Codex jobs to v1.11 and add a dependabot.yml ignore entry so this can't be silently regressed again.
avallete
approved these changes
Sep 9, 2026
jgoux
approved these changes
Sep 9, 2026
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
🤖 AI Review
The v1.11 re-pin is internally consistent, but all three Claude findings are confirmed: the blanket Dependabot ignore creates a minor dependency-maintenance risk, while duplicated rationale and inconsistent terminology are documentation nits. Codex reported no findings.
Findings
| Severity | Location | Category | Sources | Claim |
|---|---|---|---|---|
| 🟡 MINOR | .github/dependabot.yml:18 |
dependency-management |
claude | The unqualified ignore suppresses automated Dependabot update PRs for every future openai/codex-action release, leaving discovery of fixed or security-relevant releases dependent on an untracked manual check. |
| ⚪ NIT | .github/workflows/ai-review.yml:509 |
maintainability |
claude | The same 17-line version rationale is duplicated across both Codex steps, while the expected SHA is repeated in four locations without an automated consistency check, allowing a future manual update to leave stale comments or pins. |
| ⚪ NIT | .github/dependabot.yml:20 |
documentation |
claude | The Dependabot comment calls both upstream regressions hangs, although the workflow's detailed rationale describes issue #160 as a runner-level failure that kills the job. |
Stats
Claude findings: 3 · Codex findings: 0 · Confirmed: 3 · Refuted: 0 · Uncertain: 0
Models: claude-opus-5 + gpt-5.6-sol · Trigger: auto · Workflow run
This review runs once per PR. A maintainer can request another with a /ai-review comment.
Scope the dependabot.yml ignore to 1.12.x (not a blanket forever-ignore) so Dependabot still proposes v1.13+ once a fix ships, exclude the action from the actions-major group so it can't be silently bundled again, disambiguate the #151/#160 wording (hang vs. runner-killing failure), and dedupe the duplicated pin/rationale across both Codex steps with a YAML anchor/alias.
pull Bot
pushed a commit
to chizee/cli
that referenced
this pull request
Sep 9, 2026
…ase#6542) ## What kind of change does this PR introduce? CI reliability fix (follow-up to supabase#6538). ## What is the current behavior? supabase#6538 re-pinned `openai/codex-action` to v1.11 and added a Dependabot ignore entry scoped to `versions: ["1.12.x"]`, intending to still let Dependabot propose v1.13+ once the upstream hang bugs (openai/codex-action#151, supabase#160) are fixed, while blocking the known-bad v1.12 line specifically. That scoping never actually worked. 9 minutes after supabase#6538 merged, Dependabot opened supabase#6541 proposing the exact v1.12 bump we were trying to block — config propagation wasn't the issue; the `versions` syntax was. The `github-actions` ecosystem's `ignore.versions` strings are parsed as Ruby `Gem::Requirement` (RubyGems comparator syntax: `>= x`, `~> x`, etc.), not npm-style semver ranges. `"1.12.x"` isn't a wildcard in that grammar — it parses as a literal version string with an implicit `=` operator, which never equals the real dependency version (`"1.12"`), so the ignore condition silently never matched anything. Verified directly against the actual parsing logic dependabot-core uses (`Dependabot::GithubActions::Requirement`, a thin wrapper around `Gem::Requirement`): ``` GithubActionsRequirement.new("1.12.x").satisfied_by?(Gem::Version.new("1.12")) # => false (bug) GithubActionsRequirement.new(">= 1.12, < 1.13").satisfied_by?(Gem::Version.new("1.12")) # => true GithubActionsRequirement.new(">= 1.12, < 1.13").satisfied_by?(Gem::Version.new("1.12.5")) # => true GithubActionsRequirement.new(">= 1.12, < 1.13").satisfied_by?(Gem::Version.new("1.11")) # => false GithubActionsRequirement.new(">= 1.12, < 1.13").satisfied_by?(Gem::Version.new("1.13")) # => false ``` ## What is the new behavior? Replace `versions: ["1.12.x"]` with `versions: [">= 1.12, < 1.13"]` — a real Gem::Requirement comparator range, confirmed to correctly match the 1.12 line (including any 1.12.x patch) while excluding v1.11 and v1.13+. supabase#6541 should be closed as superseded once this merges.
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
3 participants
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.
What kind of change does this PR introduce?
CI reliability fix.
What is the current behavior?
AI Review's Codex jobs (
codex-review,adjudicate) intermittently hang and get killed on job timeout, discarding a completed review. Most recently: run 34323125644 on #6535 died at ~55 minutes against a 45-minute timeout.This is a regression. #6380 deliberately pinned
openai/codex-actionto v1.11 because v1.12 had a confirmed hang bug (openai/codex-action#150). #6484 — a Dependabotactions-majorgroup bump bundling 6 unrelated action updates — silently reverted that pin back to v1.12; the workflow's own comments (still saying "pinned to v1.11, NOT v1.12") went stale rather than catching the drift, since nothing diffed them against the actualuses:line.Checking upstream today turned up two separate, still-open v1.12 regressions, both matching this workflow's exact config (
safety-strategy: drop-sudo,sandbox: read-only,output-schema-file):closeevent with inherited stdio; a lingering descendant keeps the step alive forever after Codex has already written its output and finished.drop-sudorewrite chmods root-owned/runservice sockets, breakingsystemd-resolvedon the GitHub-hosted runner itself, which kills the job 52-65 minutes in regardless of the job's own timeout — matching our job's 55-minute death exactly.Neither has a released fix. Both are action-level bugs independent of the pinned Codex CLI version (reproduced across CLI versions 0.147.0-0.150.1 in the upstream threads). This is not a diff-size or token-limit problem: #6535's diff was only ~2200 lines, and v1.11 has cleanly handled 130k-270k-token diffs in under 15 minutes per the upstream reports and our own prior testing.
What is the new behavior?
openai/codex-actionto v1.11 (52fe01ec70a42f454c9d2ebd47598f9fd6893d56) in both Codex jobs — verified it's a safe drop-in, since v1.11'saction.ymlsupports every input this workflow uses.openai/codex-actionto.github/dependabot.yml'signorelist (noupdate-typesrestriction, so it blocks all automated bumps) so a grouped bump can't silently regress this pin again. Any future bump now requires a deliberate PR that checks the upstream changelog/issue tracker first.