Alert when a daily build stops producing artifacts

[mattgodbolt-molty]

A daily build that stops producing artifacts stays green, so nobody finds out. Two real cases:

• llvmflang failed for ~2 months (60 consecutive runs) before anyone noticed.
• clang_ir has reported success every day since February while building nothing, because its activity gate watched llvm/clangir, archived on 2026-02-21. Six months of a stale compiler on the site. Fixed in Rebuild ClangIR daily again #80, found by accident.

The naive version of this alert ("no successful build in N days") is too noisy to live with: a gated fork that is genuinely idle is supposed to skip for weeks, and may legitimately wake up later. We do not want to be paged about a dormant-but-healthy fork.

The fix is to alert on the discrepancy, not the silence. Three rules, each with a decisive signal rather than a heuristic:

• Upstream moved but we did not build. repos: has commits newer than last_success by more than N days. Catches a fork whose build breaks while its upstream is active. An idle fork never trips this, which is what kills the noise.
• The gate can never fire. A repos: target is archived or 404s. Catches clang_ir; the activity rule above would not have, since the dead repo has no commits by definition.
• Ungated builds must always produce. An entry with no repos: key (clang, clang_assertions, clang_llvmflang) builds unconditionally, so no successful build in N days is unambiguously broken. Catches the llvmflang case.

The data is already there: https://lambda.compiler-explorer.com/compiler-build/<name> returns last_success.timestamp, which is what build-status.md badges render. clang_ir currently returns 2026-02-22. So this needs compilers.yaml plus that endpoint plus the GitHub API, and no new build-side plumbing.

Worth deciding separately: where it reports (a scheduled workflow that opens or updates a single issue is probably enough, and is self-throttling).

[partouf]

Truth be told, it happens all the time for forks not to be committed on for weeks. This is completely normal and a waste of time/money to launch an instance over to find out that indeed there are no new commits.

The biggest problem is that we have to maintain the git urls twice, but since one is in a .sh script in multiple other repos and its in the yaml workflow here, it's a bit hard to solve that problem.

Instead I would suggest to create a tiny workflow in each of the builder's that is able to check and compare both urls and fail if the this repo is not updated with the new url. (though tbh url changes happens rarely?)