ci: require a published snapshot before bumping the moxygen pin - #668
Open
gmarzot wants to merge 1 commit into
Open
ci: require a published snapshot before bumping the moxygen pin#668gmarzot wants to merge 1 commit into
gmarzot wants to merge 1 commit into
Conversation
gmarzot
force-pushed
the
ci/sync-requires-published-snapshot
branch
from
September 2, 2026 15:14
d479bf9 to
1884206
Compare
The sync pins the newest moxygen main commit whether or not its snapshot exists. moxygen ci-main takes ~80 minutes to build and publish, so a sync landing inside that window pins a rev nothing can consume, and every moqx lane compiles the Meta stack from source instead: 49 min linux, 45/45/37 conformance, 39 macos, 34 asan. Observed on 2026-08-28 — moxygen ci-main started 68465b9 at 16:15, the sync PR opened at 16:21, the snapshot published at 17:30. Scheduled and manual runs now walk back from main until they find a rev with published assets, and skip with a warning if none of the last 20 have them, since a publish backlog is transient and a red sync every hour is not useful. repository_dispatch keeps its payload rev but fails if the assets are missing: the publish is what raises that event, so a miss means it reported a success it did not deliver.
gmarzot
force-pushed
the
ci/sync-requires-published-snapshot
branch
from
September 2, 2026 17:48
1884206 to
f5d40df
Compare
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
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 sync pins the newest moxygen main commit whether or not its snapshot exists
yet. moxygen
ci-maintakes ~80 minutes to build and publish, so a sync landinginside that window pins a rev nothing can consume, and every moqx lane compiles
the Meta stack from source instead.
Observed
2026-08-28, moxygen
68465b9:Every lane in that PR fell back to source: linux 49 min, conformance 45/45/37,
macOS 39, asan 34 — roughly four hours of runner time for a one-line pin bump.
Build-step times in the conformance lanes were 2062s, 2590s and 2620s against
286s, 212s and 280s on a normal pin bump.
Change
Scheduled and manual runs walk back from main until they find a rev whose
snapshot-<sha12>release has assets, rather than taking the newest revunconditionally.
backlog is transient; a red sync every hour is not useful.
repository_dispatchkeeps its payload rev but errors if the assets aremissing. The publish is what raises that event, so a miss means it reported a
success it did not deliver.
The cron cascade already tries to sequence this by spacing moxygen's sync at 04:23
against moqx's at 08:23. That only holds when schedules fire on time, and they
have been arriving hours late; the case above was a manual dispatch, which lands
wherever it lands. This makes the ordering a property of the data rather than of
the clock.
Verifying
gh apiprints its 404 body on stdout, so the predicate takes the exit code asthe answer and only compares a value that is actually a count — the obvious
|| echo 0form appends to the error JSON and fails the comparison withinteger expression expected, once per skipped commit.Checked against live data: the predicate returns true for the current main rev
(14 assets) and false, silently, for a nonexistent one. Selection is a no-op today
because the newest rev already has assets, which is the intended behaviour — it
only diverges inside a publish window.
This change is