feat(ci): say when the schema sync has not landed - #12483
Conversation
The Mergify JSON schemas arrive as a pull request from a bot fork, and it normally merges itself within ten minutes, so nobody watches it. When one needs a docs-side edit before it can go green — the retired `badges` tag, whose sidebar entry had to go with it — the failure is correct and invisible: the last one sat red for three days while every new schema change was force-pushed onto the same blocked branch, and the site served a stale API and configuration reference the whole time. CI already catches the breakage; nothing was reporting it. A scheduled job now fails when that pull request has been open for more than three hours, roughly ten times its usual time to merge, so an ordinary sync never trips it. A failing scheduled run shows red in the Actions tab and mails whoever last touched the workflow file, and fixing the sync clears it. The build-time guard keeps its own job, and its comment no longer claims the sync bypasses pull request CI — it does not. What the deploy build catches is the case per-pull-request CI cannot: a sync that retires a tag and an unrelated edit that links it are each green alone and broken once both are on main. Its error message now covers a retired tag as well as a renamed one, since telling the reader to repoint an entry at a slug that no longer exists is a dead end. MRGFY-8814 Change-Id: I6e907e5617e318d75718553c48f965b3738e3d80
Member
Author
|
This pull request is part of a Mergify stack:
|
Contributor
Merge Protections🔴 3 of 7 protections blocking · waiting on 👀 reviews and ⛓️ dependency
🔴 ⛓️ Depends-On RequirementsWaiting for
This rule is failing.Requirement based on the presence of
🔴 👀 Review RequirementsWaiting for
This rule is failing.
🔴 🔎 ReviewsWaiting for
This rule is failing.
Show 4 satisfied protections🟢 🤖 Continuous Integration
🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 📕 PR description
🟢 🚦 Auto-queueWhen all merge protections are satisfied, this pull request will be queued automatically. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Mergify JSON schemas arrive as a pull request from a bot fork, and it
normally merges itself within ten minutes, so nobody watches it. When one
needs a docs-side edit before it can go green — the retired
badgestag, whosesidebar entry had to go with it — the failure is correct and invisible: the
last one sat red for three days while every new schema change was force-pushed
onto the same blocked branch, and the site served a stale API and configuration
reference the whole time.
CI already catches the breakage; nothing was reporting it. A scheduled job now
fails when that pull request has been open for more than three hours, roughly
ten times its usual time to merge, so an ordinary sync never trips it. A
failing scheduled run shows red in the Actions tab and mails whoever last
touched the workflow file, and fixing the sync clears it.
The build-time guard keeps its own job, and its comment no longer claims the
sync bypasses pull request CI — it does not. What the deploy build catches is
the case per-pull-request CI cannot: a sync that retires a tag and an unrelated
edit that links it are each green alone and broken once both are on main. Its
error message now covers a retired tag as well as a renamed one, since telling
the reader to repoint an entry at a slug that no longer exists is a dead end.
MRGFY-8814
Depends-On: #12482