ci: make PR validation unconditional - the paths filter silently skipped whole classes of pull requests #103

Merged

abiba-bot merged 1 commits from fm/ci-paths-filter-skips-deliverables-prs-20260915 into master 2026-09-15 12:53:21 +00:00

Conversation 0 Commits 1 Files Changed 1

+9 -10

abiba-bot commented 2026-09-15 12:28:05 +00:00

Owner

Copy Link

Copy Source

Fixes a hole in the quality gate: pull requests that touched none of the workflow's four allowed path patterns produced no Gitea Actions run at all, so validation, lint, the AI review and the merge gate were silently skipped.

The defect (reported by the kagentz PR-review agent, relay #773; reproduced independently)

.gitea/workflows/pr-pipeline.yaml gated both push and pull_request on paths: ['**.prose.md', 'scripts/**.sh', '**.yaml', '**.yml']. Consequences:

• PR #77 (deliverables/-only) has never had a run - actions/runs?head_sha=0c7d7be5 returns total_count: 0, including after an empty-commit retrigger.
• Broader than the reported case: a PR touching only scripts/*.py, bin/*, or .md also skipped everything. Several of our own recent PRs only ran CI because they happened to include contract prose.

Change (one file, .gitea/workflows/pr-pipeline.yaml)

• The paths: filter is removed from BOTH triggers; PR validation is now unconditional, and the push trigger keeps branches: [master].
• An in-file comment records why the trigger is unfiltered and forbids re-adding a paths: filter.
• The jobs: section is byte-identical to master (sha256 e9fc8ad4... on both sides) - no job, step, needs or if was touched.

Verification performed (control/treatment, raw API output preserved in the lane's report)

• CONTROL: scratch PR #98 = current master (old filtered workflow) + only deliverables/probe-control.md. Run count for its head 2db13d24: 0, stable across 10 polls 25s apart, and its diff contains no workflow file, so the old **.yaml rule cannot mask the result. The real-world instance reproduces too: PR #77's head -> total_count: 0.
• TREATMENT: scratch PR #99 = the SAME deliverables-only change on a scratch base carrying the fixed workflow. Run 315 appeared (pull_request, conclusion success, all five jobs green - auth/validate/lint/ai-review/gate). Because #99's diff was deliverables-only, this isolates the trigger rather than the diff.
• REGRESSION: scratch PR #102, an ordinary contract edit against the fixed workflow - run 318, five jobs green.
• SEMANTICS (probed, not inferred): on this Gitea 1.27.0, a pull_request run resolves the workflow from the PR HEAD (refs/pull/<n>/head, visible as "path": "pr-pipeline.yaml@refs/pull/<n>/head" in the run metadata) and evaluates paths: against the whole PR diff. Probe: a PR with a marker job only on its base branch ran exactly the five head jobs, no marker - so head wins. Second probe: a PR whose first commit matched the old filter but whose latest commit touched only deliverables/ still produced a run - so the whole diff is inspected, not the last commit.
• CONSEQUENCE, stated so nobody expects magic: because the workflow comes from the head, PR #77 will still produce no run after this merges - its head was cut before the fix. It needs a rebase or a fresh commit on its head. This fix closes the hole going forward, not retroactively; firstmate will re-run #77 after merge.
• All five scratch PRs were closed unmerged and all seven scratch branches deleted (HTTP 204 each, re-queried clean). PR #77 was not touched.

Reviewers: confirm the jobs: section is unchanged (compare the sha256 above), that no paths: filter remains on either trigger, and that the comment cannot be mistaken for decoration. The behaviour itself is already demonstrated by the scratch runs quoted above.

Fixes a hole in the quality gate: pull requests that touched none of the workflow's four allowed path patterns produced **no Gitea Actions run at all**, so validation, lint, the AI review and the merge gate were silently skipped. ## The defect (reported by the kagentz PR-review agent, relay #773; reproduced independently) `.gitea/workflows/pr-pipeline.yaml` gated both `push` and `pull_request` on `paths: ['**.prose.md', 'scripts/**.sh', '**.yaml', '**.yml']`. Consequences: - PR #77 (`deliverables/`-only) has **never had a run** - `actions/runs?head_sha=0c7d7be5` returns `total_count: 0`, including after an empty-commit retrigger. - Broader than the reported case: a PR touching only `scripts/*.py`, `bin/*`, or `.md` also skipped everything. Several of our own recent PRs only ran CI because they happened to include contract prose. ## Change (one file, `.gitea/workflows/pr-pipeline.yaml`) - The `paths:` filter is removed from BOTH triggers; PR validation is now unconditional, and the `push` trigger keeps `branches: [master]`. - An in-file comment records why the trigger is unfiltered and forbids re-adding a `paths:` filter. - The `jobs:` section is **byte-identical to master** (sha256 `e9fc8ad4...` on both sides) - no job, step, `needs` or `if` was touched. ## Verification performed (control/treatment, raw API output preserved in the lane's report) - **CONTROL**: scratch PR #98 = current master (old filtered workflow) + only `deliverables/probe-control.md`. Run count for its head `2db13d24`: **0**, stable across 10 polls 25s apart, and its diff contains no workflow file, so the old `**.yaml` rule cannot mask the result. The real-world instance reproduces too: PR #77's head -> `total_count: 0`. - **TREATMENT**: scratch PR #99 = the SAME deliverables-only change on a scratch base carrying the fixed workflow. Run **315** appeared (`pull_request`, conclusion success, all five jobs green - auth/validate/lint/ai-review/gate). Because #99's diff was deliverables-only, this isolates the trigger rather than the diff. - **REGRESSION**: scratch PR #102, an ordinary contract edit against the fixed workflow - run **318**, five jobs green. - **SEMANTICS (probed, not inferred)**: on this Gitea 1.27.0, a `pull_request` run resolves the workflow from the **PR HEAD** (`refs/pull/<n>/head`, visible as `"path": "pr-pipeline.yaml@refs/pull/<n>/head"` in the run metadata) and evaluates `paths:` against the **whole PR diff**. Probe: a PR with a marker job only on its base branch ran exactly the five head jobs, no marker - so head wins. Second probe: a PR whose first commit matched the old filter but whose latest commit touched only `deliverables/` still produced a run - so the whole diff is inspected, not the last commit. - **CONSEQUENCE, stated so nobody expects magic**: because the workflow comes from the head, **PR #77 will still produce no run after this merges** - its head was cut before the fix. It needs a rebase or a fresh commit on its head. This fix closes the hole going forward, not retroactively; firstmate will re-run #77 after merge. - All five scratch PRs were closed unmerged and all seven scratch branches deleted (`HTTP 204` each, re-queried clean). PR #77 was not touched. Reviewers: confirm the `jobs:` section is unchanged (compare the sha256 above), that no `paths:` filter remains on either trigger, and that the comment cannot be mistaken for decoration. The behaviour itself is already demonstrated by the scratch runs quoted above.

abiba-bot added 1 commit 2026-09-15 12:28:06 +00:00

ci: make PR validation trigger unconditional (remove paths filter) ... 5053a33e2c

The pr-pipeline workflow filtered both push and pull_request on
paths (**.prose.md, scripts/**.sh, **.yaml, **.yml). A PR whose diff
touched none of those paths — e.g. PR #77, deliverables/-only —
produced no Gitea Actions run at all, so validate/lint/ai-review and
the merge gate were silently skipped.

Remove the paths filter from both triggers and record in the file
that the trigger is intentionally unfiltered. No job, step, needs,
if or command is changed.

abiba-bot merged commit fe6eb35291 into master 2026-09-15 12:53:21 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

abiba-bot jerome (Jerome Kwame Tabiri) kagentz-bot kwame (Kwame Tabiri) mumuni-bot (Mumuni 🦅 (Syslog Falcon)) tanko-bot theo

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: SyslogSolution/prose-contracts#103