Skip to content

Pin CI to a known-good Mojo nightly; check drift weekly - #5

Merged
conorbronsdon merged 1 commit into
mainfrom
pin-mojo-nightly
Jul 31, 2026
Merged

Pin CI to a known-good Mojo nightly; check drift weekly#5
conorbronsdon merged 1 commit into
mainfrom
pin-mojo-nightly

Conversation

@conorbronsdon

Copy link
Copy Markdown
Owner

Both workflows installed mojo from the nightly index with --prerelease allow and no version pin, so every run resolved whatever nightly was current. That's why six repos in this suite went green on 7/29 and red on 7/31 with no commits in between — a frozen library's CI decaying on its own, surfacing on unrelated docs PRs.

Pin. MOJO_VERSION: 1.0.0b3.dev2026073014 — the nightly all 11 repos went green on today. Pushes and PRs install exactly it, so upstream churn can't turn a green repo red without a commit.

Weekly drift check. Pinning alone trades one problem for a worse one — silence. So test.yml also runs Mondays against the latest nightly:

  • It fires on main, so it never gates a PR.
  • On failure it opens a drift issue, or comments on the existing one so it doesn't file 52 a year. A red X on the Actions tab of a frozen repo isn't a signal; an issue is.
  • Cron minutes are staggered across the 11 repos rather than all firing at once.

Why this reuses test.yml instead of a new workflow file. Each repo's test steps are bespoke. A separate nightly-latest.yml would have to duplicate them and would silently drift out of sync. One workflow, one branch on github.event_name.

docs.yaml is pinned but not scheduled — it deploys Pages and a weekly redeploy isn't wanted. mojo doc compiles the sources, so the test job catches the same stdlib breakage regardless.

Verified before pushing: all 22 workflow files parse as valid YAML with the correct pin and distinct cron minutes; the drift step's script was extracted from parsed YAML and executed with gh stubbed, confirming it creates an issue when none exists and comments when one does. Landed and CI-verified on conorbronsdon/mojo-feed#6 first, where the run log shows + mojo==1.0.0b3.dev2026073014 — the pin, not latest.

When this fires: fix the breakage, then bump MOJO_VERSION in both files to the nightly that passes.

🤖 Generated with Claude Code

Both workflows installed `mojo` from the nightly index unpinned, so every run
resolved whatever nightly was current. That is why this repo went green on 7/29
and red on 7/31 with no commits in between -- a frozen library's CI decayed on
its own, and the breakage surfaced on an unrelated docs PR.

CI now installs exactly the nightly the repo is known to pass on. Upstream churn
can no longer turn a green repo red without a commit.

Pinning alone would trade one problem for a worse one: silence. So test.yml also
runs weekly against the LATEST nightly. That run is advisory -- it fires on main,
so it never gates a PR -- and on failure it opens (or comments on) a drift issue,
because a red X on the Actions tab of a repo nobody is watching is not a signal.

The weekly check reuses test.yml rather than living in its own file. A separate
workflow would have to duplicate this repo's bespoke test steps and would drift
out of sync with them.

docs.yaml is pinned but not scheduled -- it deploys Pages, and a weekly redeploy
is not wanted. `mojo doc` compiles the sources, so the test job catches the same
stdlib breakage anyway.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@conorbronsdon
conorbronsdon merged commit 30f34af into main Jul 31, 2026
1 check passed
@conorbronsdon
conorbronsdon deleted the pin-mojo-nightly branch July 31, 2026 21:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant