From eeecf25e24a82f77b23a8a566baf370be8dafeb6 Mon Sep 17 00:00:00 2001 From: Fanboynz Date: Sun, 13 Sep 2026 00:35:34 +1200 Subject: [PATCH 1/2] ci: let the parity gate see main, so drift stops ambushing other PRs The gate was path filtered to Tools/ on BOTH triggers. One of its tests is not about the scanner at all: the repository acceptance asserts the checked-in authority still reproduces from the CURRENT product source. Product changes are exactly what invalidates it, and product changes were the one thing the filter excluded. So main could carry stale authority indefinitely with nothing red, until some later PR touched Tools/ and inherited the whole accumulated drift. Four staleness events now, and three landed on an outside contributor's PR that had caused none of it. Tonight's was #2141: the same 4308 against 4310 and the same hashes failed on main, on that branch, and at 0b0d206 before any of today's merges. The push trigger loses its filter. Drift now surfaces on the merge that caused it, on main, where re-deriving is a two-minute maintainer action, rather than weeks later on someone else's work. The pull_request filter is unchanged on purpose. The reason it exists is sound, that ordinary product changes should not re-run a multi-minute self-test of the scanner, and with main kept fresh there is no longer anything for a PR to inherit. Cost is ~2.5 minutes of ubuntu Python per push to main. This does NOT fix the deeper problem, which is that --refresh-derived cannot repair any of this: it fails "migration required" because the checked-in authority cannot be reproduced from the base, so the only route is deleting both snapshots and re-bootstrapping, which no contributor can do. All this change does is make the maintainer the one who finds out. --- .github/workflows/parity-governance.yml | 27 ++++++++++++++++--------- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/.github/workflows/parity-governance.yml b/.github/workflows/parity-governance.yml index 6f15151a83..f4a81eceee 100644 --- a/.github/workflows/parity-governance.yml +++ b/.github/workflows/parity-governance.yml @@ -1,7 +1,20 @@ -# These are the scanner's own unit and repository-acceptance tests. Run the -# multi-minute suite when its implementation, authority, tests, or workflow -# changes; ordinary product-source changes belong to the later ledger/ratchet -# gate, not to repeated self-testing of the scanner. +# These are the scanner's own unit and repository-acceptance tests. +# +# On a PULL REQUEST, run the multi-minute suite only when its implementation, +# authority, tests or workflow change; ordinary product-source changes belong to +# the later ledger/ratchet gate, not to repeated self-testing of the scanner. +# +# On a PUSH TO MAIN, run it unconditionally. One of these tests is not about the +# scanner at all: the repository acceptance asserts that the checked-in authority +# still reproduces from the CURRENT product source. Product changes are exactly +# what invalidates it, so filtering this trigger to Tools/ meant main could carry +# stale authority indefinitely with nothing red, until some later PR touched +# Tools/ and inherited the whole accumulated drift. +# +# That happened four times, and three landed on an outside contributor's PR that +# had not caused any of it. The suite is Python-only and costs ~2.5 minutes; a +# red main on the merge that caused the drift is the signal, and re-deriving is +# a two-minute maintainer action. See the history in #1534. name: Parity Governance CI on: @@ -15,12 +28,6 @@ on: - '.github/workflows/parity-governance.yml' push: branches: [main] - paths: - - 'Tools/issue_ref.py' - - 'Tools/parity_*.py' - - 'Tools/parity_*.json' - - 'Tools/tests/**' - - '.github/workflows/parity-governance.yml' workflow_dispatch: concurrency: From d721c70c14650a10d04b1484e7601267392d5648 Mon Sep 17 00:00:00 2001 From: Fanboynz Date: Sun, 13 Sep 2026 00:45:06 +1200 Subject: [PATCH 2/2] ci: find parity authority staleness on a schedule, not on someone's PR The suite is path filtered to Tools/ on both triggers, but one of its tests is not about the scanner at all: the repository acceptance asserts the checked-in authority still reproduces from the CURRENT product source. Product changes are what invalidates it, and product changes are exactly what both filters exclude. So main could carry stale authority indefinitely with nothing red, until some later PR touched Tools/ and inherited the whole accumulated drift. Four staleness events now, three of them landing on an outside contributor's PR that caused none of it. Tonight was #2141: the same 4308 against 4310 and the same hashes failing on main, on that branch, and at 0b0d206 before any of today's merges. A daily run on main finds it within a day, where re-deriving is a two-minute maintainer action. Deliberately a schedule rather than an unfiltered push. My first attempt removed the push filter, and the suite's own test_core_tools_filter_covers_every_governance_tool_path caught it: that test pins BOTH filters and forbids product globs, so not running on product source is a deliberate invariant rather than an oversight. A periodic check keeps it true. Both path lists are therefore untouched and that test passes unchanged. This does NOT make drift repairable. --refresh-derived still fails "migration required" because the checked-in authority cannot be reproduced from the base, so the only route remains deleting both snapshots and re-bootstrapping, which no contributor can do. All this does is make the maintainer the one who finds out. --- .github/workflows/parity-governance.yml | 33 ++++++++++++++++++------- 1 file changed, 24 insertions(+), 9 deletions(-) diff --git a/.github/workflows/parity-governance.yml b/.github/workflows/parity-governance.yml index f4a81eceee..e20b995ecf 100644 --- a/.github/workflows/parity-governance.yml +++ b/.github/workflows/parity-governance.yml @@ -4,17 +4,22 @@ # authority, tests or workflow change; ordinary product-source changes belong to # the later ledger/ratchet gate, not to repeated self-testing of the scanner. # -# On a PUSH TO MAIN, run it unconditionally. One of these tests is not about the -# scanner at all: the repository acceptance asserts that the checked-in authority -# still reproduces from the CURRENT product source. Product changes are exactly -# what invalidates it, so filtering this trigger to Tools/ meant main could carry -# stale authority indefinitely with nothing red, until some later PR touched -# Tools/ and inherited the whole accumulated drift. +# It also runs DAILY on main. One of these tests is not about the scanner at +# all: the repository acceptance asserts that the checked-in authority still +# reproduces from the CURRENT product source. Product changes are what +# invalidates it, and product changes are exactly what both filters exclude, so +# main could carry stale authority indefinitely with nothing red until some +# later PR touched Tools/ and inherited the whole accumulated drift. # # That happened four times, and three landed on an outside contributor's PR that -# had not caused any of it. The suite is Python-only and costs ~2.5 minutes; a -# red main on the merge that caused the drift is the signal, and re-deriving is -# a two-minute maintainer action. See the history in #1534. +# had caused none of it. The schedule finds it within a day, on main, where +# re-deriving is a two-minute maintainer action. +# +# Deliberately a schedule rather than an unfiltered push: this suite is pinned +# NOT to run on product source (see test_core_tools_filter_covers_every_ +# governance_tool_path, which asserts both filters and forbids product globs), +# and a periodic check keeps that true. See the history in #1534. + name: Parity Governance CI on: @@ -28,6 +33,16 @@ on: - '.github/workflows/parity-governance.yml' push: branches: [main] + paths: + - 'Tools/issue_ref.py' + - 'Tools/parity_*.py' + - 'Tools/parity_*.json' + - 'Tools/tests/**' + - '.github/workflows/parity-governance.yml' + # Daily, so authority staleness is found on a schedule instead of by whoever + # next edits Tools/. See the header note. + schedule: + - cron: '17 4 * * *' workflow_dispatch: concurrency: