Skip to content

fix(ci): rewrite dev-enforcement — it had never run a single job - #786

Open
gHashTag wants to merge 2 commits into
mainfrom
fix/trinity-dev-enforcement
Open

fix(ci): rewrite dev-enforcement — it had never run a single job#786
gHashTag wants to merge 2 commits into
mainfrom
fix/trinity-dev-enforcement

Conversation

@gHashTag

Copy link
Copy Markdown
Owner

.github/workflows/dev-enforcement.yml has been red on every push to main, and
the red X carries the file path instead of the workflow's name: — which is
GitHub's way of saying the YAML did not compile. Zero jobs, ever.

Five faults, each of which looked like the one below it:

  1. YAML does not parse. In pr-status, steps: is indented inside if:,
    and below it run: inside if:.
  2. No actions/checkout in any jobgit log -1 ran outside a repository,
    and .trinity/dev_session.json was never on disk.
  3. $COMMIT is never assigned, so the issue-ID test read an empty string
    and could only ever print "Missing issue ID" — for correct commits too.
  4. The regex cannot match: ^\[a-f]+\(... requires a literal [ at the
    start of the subject. Its result was piped to head -1 and discarded anyway.
  5. session-check gates CI on local working state. CI cannot observe a dev
    session; on main it asserts whatever state happened to be committed.

Fixing only the indentation would have turned "never ran" into "fails every
push", which is worse.

Reporting, not blocking — deliberately different from trinity-fpga

Measured on the last 60 non-merge commits of each main:

repository would fail
trinity-fpga 3 / 60 (5%)
trinity 25 / 60 (42%)

This repository's practice is largely prose subjects, many in Russian
(Локализовать ветвь дерева технологий (#785)), while CLAUDE.md documents
<type>(<scope>): <description>.

That gap is a policy question, and not one a gate should settle by fiat: a check
that fails 42% of the work is a check people route around. So it reports counts
and warnings, and the decision to tighten it — or to change the documented rule
— stays with you. The trinity-fpga copy blocks on PRs because 5% is a different
situation.

🤖 Generated with Claude Code

gHashTag and others added 2 commits August 15, 2026 18:57
Same five faults as the trinity-fpga copy: the YAML did not parse
('steps:' indented inside 'if:', then 'run:' inside 'if:', so GitHub
compiled zero jobs and titled the run by its file path); no job had a
checkout, so 'git log' ran outside a repository; $COMMIT was never
assigned, so the issue test could only print 'Missing issue ID'; the
regex required a literal '[' at the start of the subject; and
session-check gated CI on local dev-session state that CI cannot see.

Reporting, not blocking, and that differs from the trinity-fpga copy on
purpose. Measured on the last 60 non-merge commits of each main:

  trinity-fpga     3 / 60   ( 5%) would fail
  trinity         25 / 60   (42%) would fail

This repository's practice is largely prose subjects, many in Russian,
while CLAUDE.md documents <type>(<scope>): <description>. That gap is a
policy question, not something to settle by switching a gate to
blocking: a check failing 42% of the work is a check people route
around. It reports counts and leaves the decision to a reader who can
also change the rule.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…n PRs

  fetch-depth: ${{ github.event_name == 'pull_request' && 0 || 1 }}

evaluates to 1 on a pull request, not 0: 'true && 0' is '0', '0' is
falsy, so '|| 1' wins. The clone was shallow and the job died with

  fatal: Invalid revision range 1bbe926..59c991c

which reads as a bad SHA rather than as a missing object. Caught on this
PR's own first run. The idiom is only safe when the middle operand is
truthy.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant