Decide: should main require its CI checks before a merge? #50

New Issue

fabi · 2026-09-17T19:02:11Z

fabi commented

2026-09-17 19:02:11 +00:00

Branch protection on main, read from the API on 2026-09-17:

required_approvals        1
enable_merge_whitelist    true   (merge_whitelist_usernames: ['fabi'])
enable_status_check       false  (status_check_contexts: none)
block_admin_merge_override false

Nothing requires CI to pass before a merge — a red main merges as easily as a green one, so the green that #11/#12/#13 worked for is advisory.

If it is switched on, start with Native — linux alone:

this repo has one aarch64 runner, and a required context that flakes blocks every merge, including the fix for the flake;
WASM — Web has already produced a green that certified nothing (the data-bin vs data-target-name finding on #11 — both selectors exit 0, one builds a 1,478-byte artifact with no entry point);
CI has no disc, so its green is parser-only either way — see #16.

Human's call. Filed because the decision has been carried in session notes rather than here.

Branch protection on `main`, read from the API on 2026-09-17: ``` required_approvals 1 enable_merge_whitelist true (merge_whitelist_usernames: ['fabi']) enable_status_check false (status_check_contexts: none) block_admin_merge_override false ``` **Nothing requires CI to pass before a merge** — a red `main` merges as easily as a green one, so the green that #11/#12/#13 worked for is advisory. If it is switched on, start with **`Native — linux` alone**: * this repo has one aarch64 runner, and a required context that flakes blocks *every* merge, including the fix for the flake; * `WASM — Web` has already produced a green that certified nothing (the `data-bin` vs `data-target-name` finding on #11 — both selectors exit 0, one builds a 1,478-byte artifact with no entry point); * CI has no disc, so its green is parser-only either way — see #16. Human's call. Filed because the decision has been carried in session notes rather than here.

fabi added the kind/ask state/needs-human labels 2026-09-17 19:02:11 +00:00

fabi commented

2026-09-19 18:54:55 +00:00

Decided: no. main will not require its CI checks before a merge.

The runner is a single Raspberry Pi and is slow; gating every merge behind it would make the queue the bottleneck for a one-maintainer repo. CI stays advisory — it runs on PRs and its result is read, but it does not block.

Worth recording so this is not re-litigated on a red run: the Pi has no disc corpus, so a green CI means parser-only coverage. The real gate is a full cargo test --workspace --no-fail-fast with all three corpora present, which only a dev box can run — measured at 45 suites / 377 passed / 0 failed / 14 ignored (2026-09-19, main + #53/#57/#58, default container caps).

Closing as decided.

**Decided: no.** `main` will not require its CI checks before a merge. The runner is a single Raspberry Pi and is slow; gating every merge behind it would make the queue the bottleneck for a one-maintainer repo. CI stays advisory — it runs on PRs and its result is read, but it does not block. Worth recording so this is not re-litigated on a red run: the Pi has **no disc corpus**, so a green CI means *parser-only* coverage. The real gate is a full `cargo test --workspace --no-fail-fast` with all three corpora present, which only a dev box can run — measured at **45 suites / 377 passed / 0 failed / 14 ignored** (2026-09-19, `main` + #53/#57/#58, default container caps). Closing as decided.

fabi closed this issue

2026-09-19 18:54:56 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: fabi/Sylpheed#50

Decide: should main require its CI checks before a merge? #50

Decide: should `main` require its CI checks before a merge? #50