The 'main' ruleset is active but inert — it targets no refs, and its required checks match no job

[eaitbrahim]

Found while making CI manual-only (#234). Recording it because it is currently providing zero protection while appearing configured.

What's there

ruleset "main"  (id 20701832, created 2026-08-11 11:20)
  enforcement: ACTIVE
  conditions.ref_name.include: []
  conditions.ref_name.exclude: []
  required_status_checks: "Lint, Unit tests, Build", "Integration Tests"
  required approving reviews: 1

Authoritative check — GET /repos/CodeGateSoftware/keel/rules/branches/main returns []: 0 rules in force on main.

(Note GET /branches/main/protection returns 404 "Branch not protected". That is the classic protection API and does not see rulesets, which is why this was initially missed.)

Two independent defects

1. It targets nothing. include is empty, so the ruleset matches no ref. Enforcement is active but there is nothing to enforce it on.
2. Its required checks match no job in this repo. It requires contexts "Lint, Unit tests, Build" and "Integration Tests". The jobs this repo actually defines are test (ci.yml), migrate (migrate.yml), and release (release.yml). Those contexts look copied from a different project.

Defect 2 is the dangerous one: fixing only the targeting would block every PR forever, waiting on status checks that can never report.

Why it matters now

#234 makes ci.yml workflow_dispatch-only, so nothing verifies a PR automatically before merge. That was an accepted trade — but it was accepted on the understanding that no branch protection existed. In fact a ruleset exists and is simply not working, which is a different and more fixable situation.

To fix, both halves are needed

• Set conditions.ref_name.include to ["~DEFAULT_BRANCH"] (or refs/heads/main).
• Replace the required contexts with ones this repo actually produces. With CI now manual-only, the honest options are to require no status checks (review-only), or to restore an automatic trigger for the one check you want to require. Requiring test while ci.yml only runs on dispatch would mean a human must remember to dispatch CI on every PR before it can merge.

Decide the intent first — review-only gate, or automatic check + required context — because the two halves have to agree.

[eaitbrahim]

Fixed. Both halves landed together, as the issue required.

The workflow half — #238 added pull_request alongside push: [main], so the job reports a status named test on a PR:

on:
  pull_request:      # GATES the merge -- the ruleset requires this context
  push:
    branches: [main] # VERIFIES the tree the merge produced
  workflow_dispatch:

The ruleset half — repointed and corrected:

include: [~DEFAULT_BRANCH]      (was [])
required_status_checks: [test]  (was "Lint, Unit tests, Build", "Integration Tests")
strict: false                   (was true)
rules in force on main: deletion, non_fast_forward, required_status_checks

Was 0 rules in force; GET /rules/branches/main now returns all three.

Verified both directions, not assumed

A throwaway PR branched from a main that lacked the trigger reported no test check and came back mergeStateStatus: BLOCKED. #238, whose own branch carried the trigger, reported test pass and came back CLEAN. The probe was closed and its branch deleted.

The post-merge push run also fired and passed on main at 90e87a8 — the trigger that had never been exercised.

Two decisions made along the way

The 1-approving-review rule was removed. With bypass_actors: [] it would have made it impossible to merge your own PRs — GitHub does not permit self-approval, so every PR would have needed mehdilamkies-prog. The gate is now the suite, not a second pair of eyes.

strict is off. A branch no longer has to be rebased onto latest main before merging; the post-merge push run catches a semantic conflict between two independently-green branches a few minutes after the fact instead of forcing a re-run on every open PR each time main moves.

deletion and non_fast_forward were kept as they were.

One coupling now written into the workflow comment

The context is test only because the job is test: and declares no name:. Renaming that job, or giving it a name:, silently changes the reported context and re-breaks the ruleset with no error anywhere — which is exactly how this issue arose. The comment says so at the trigger.