Symptom
Any PR that doesn't touch `src/workers/` or `docker/` is BLOCKED forever. The PrimaryBranches ruleset requires `verify-architectures`, `verify-after-rebuild`, and `validate` as status checks. The Verify Docker Images workflow only fires on PRs whose paths match those two narrow patterns. So a TS-only or scripts-only PR has no entry for `verify-architectures` / `verify-after-rebuild` in its check rollup, GitHub treats those as still pending, and `mergeStateStatus` is BLOCKED indefinitely.
Empirical hits today:
Root cause
`.github/workflows/docker-images.yml`:
```yaml
on:
push:
branches: [main]
paths:
- 'src/workers/'
- 'src/examples/widget-ui/'
- 'src//*.ts' # ← wider on push
- 'docker/'
- 'docker-compose.yml'
pull_request:
branches: [main]
paths:
- 'src/workers/' # ← narrower on PR
- 'docker/'
```
`pull_request` paths are a strict subset of `push` paths. Any PR whose changes are entirely in the push-only subset (notably `src/**/*.ts` outside `src/workers`, plus everything in `scripts/`, `docs/`, configs, etc.) cannot satisfy the required checks.
Fix options
Option A — match PR paths to push paths, plus scripts/
```yaml
pull_request:
branches: [main]
paths:
- 'src/workers/'
- 'src/examples/widget-ui/'
- 'src//*.ts'
- 'docker/'
- 'docker-compose.yml'
- 'scripts/**' # push-current-arch.sh / push-image.sh affect what CI verifies
```
PRs that don't touch any of these paths still don't trigger the workflow — but those PRs (e.g. doc-only PRs) shouldn't be required to satisfy verify-architectures anyway. Combine with Option B below to handle the truly-irrelevant-PR case.
Option B — passthrough job that publishes the required check names
Add a tiny separate workflow that runs on EVERY PR (no path filter) and emits success status for `verify-architectures` / `verify-after-rebuild` IF the PR's paths don't match the docker-relevant set. That way doc-only or config-only PRs satisfy the ruleset without faking docker verification.
Option C — change the rulesets
Make `verify-architectures` / `verify-after-rebuild` non-required on PRs that don't touch the relevant paths. GitHub rulesets don't natively support path-conditional required checks; this would mean removing them as required entirely and relying on path-triggered runs to gate merges informally.
Recommendation
Option A + B. A widens the trigger to catch all relevant changes; B handles truly-irrelevant PRs cleanly.
Why this matters
Today, three follow-up PRs (#972, #973, plus this one if doc-only) are stuck behind a workflow misconfiguration. Joel had to admin-merge or rebase-into-Rust-touching-PR to land any non-Rust change. The workflow path filter is the surgical place to fix it.
Notes
The workflow YAML edit requires `workflow` OAuth scope, which the current AI push lane lacks. Filing as an issue rather than a PR for that reason. Happy to draft the YAML diff in a comment once admin pushes it.
Symptom
Any PR that doesn't touch `src/workers/` or `docker/` is BLOCKED forever. The PrimaryBranches ruleset requires `verify-architectures`, `verify-after-rebuild`, and `validate` as status checks. The Verify Docker Images workflow only fires on PRs whose paths match those two narrow patterns. So a TS-only or scripts-only PR has no entry for `verify-architectures` / `verify-after-rebuild` in its check rollup, GitHub treats those as still pending, and `mergeStateStatus` is BLOCKED indefinitely.
Empirical hits today:
git worktree add(closes #966) #972 `fix(push-script)` — only changes `scripts/push-current-arch.sh`. BLOCKED.Root cause
`.github/workflows/docker-images.yml`:
```yaml
on:
push:
branches: [main]
paths:
- 'src/workers/'
- 'src/examples/widget-ui/'
- 'src//*.ts' # ← wider on push
- 'docker/'
- 'docker-compose.yml'
pull_request:
branches: [main]
paths:
- 'src/workers/' # ← narrower on PR
- 'docker/'
```
`pull_request` paths are a strict subset of `push` paths. Any PR whose changes are entirely in the push-only subset (notably `src/**/*.ts` outside `src/workers`, plus everything in `scripts/`, `docs/`, configs, etc.) cannot satisfy the required checks.
Fix options
Option A — match PR paths to push paths, plus scripts/
```yaml
pull_request:
branches: [main]
paths:
- 'src/workers/'
- 'src/examples/widget-ui/'
- 'src//*.ts'
- 'docker/'
- 'docker-compose.yml'
- 'scripts/**' # push-current-arch.sh / push-image.sh affect what CI verifies
```
PRs that don't touch any of these paths still don't trigger the workflow — but those PRs (e.g. doc-only PRs) shouldn't be required to satisfy verify-architectures anyway. Combine with Option B below to handle the truly-irrelevant-PR case.
Option B — passthrough job that publishes the required check names
Add a tiny separate workflow that runs on EVERY PR (no path filter) and emits success status for `verify-architectures` / `verify-after-rebuild` IF the PR's paths don't match the docker-relevant set. That way doc-only or config-only PRs satisfy the ruleset without faking docker verification.
Option C — change the rulesets
Make `verify-architectures` / `verify-after-rebuild` non-required on PRs that don't touch the relevant paths. GitHub rulesets don't natively support path-conditional required checks; this would mean removing them as required entirely and relying on path-triggered runs to gate merges informally.
Recommendation
Option A + B. A widens the trigger to catch all relevant changes; B handles truly-irrelevant PRs cleanly.
Why this matters
Today, three follow-up PRs (#972, #973, plus this one if doc-only) are stuck behind a workflow misconfiguration. Joel had to admin-merge or rebase-into-Rust-touching-PR to land any non-Rust change. The workflow path filter is the surgical place to fix it.
Notes
The workflow YAML edit requires `workflow` OAuth scope, which the current AI push lane lacks. Filing as an issue rather than a PR for that reason. Happy to draft the YAML diff in a comment once admin pushes it.