* .github/workflows/GnuTests.yml (Fetch reference results): Retry the
branch lookup and treat only a 404 as "nothing published yet"; a
transient API error used to look like a missing baseline and silently
skip both comparisons, letting a regression through unnoticed.
(Publish to the reference branch): Same for the published run id, which
guards the force-push. A suppressed error read as run id 0 would let
this run overwrite a reference a newer run had already placed.
* .github/workflows/NotifyTracking.yml: Do not name a cadence for the
tracking repository's fallback schedule, which is its own to change.
* .github/workflows/GnuTests.yml (Fetch reference results): Resolve the
reference branch tip once and read every file at that commit. The
branch is force-pushed by 'publish-reference', so reading each file by
branch name could straddle a publish and pair one file with another
reference's, comparing against a baseline that never existed.
* .github/workflows/NotifyTracking.yml (jobs.dispatch.if): Dispatch for
any completed run, not only a successful one. 'GnuTests' uploads its
results and only then fails the comparison when it finds a new failure,
and 'publish-reference' publishes regardless, so requiring success left
the graphs un-refreshed for exactly the regressions they exist to show.
* .github/workflows/NotifyTracking.yml (jobs.dispatch.env): Add
HAVE_APP_CREDENTIALS; the 'secrets' context is not available in a step's
'if:', where it fails with "Unrecognized named-value: 'secrets'", so the
check has to go through a job-level env var.
* .github/workflows/GnuTests.yml (jobs.publish-reference.concurrency):
Serialize publishing. The step reads the published run id and then
force-pushes, so two overlapping runs could interleave those and let an
older one overwrite a newer reference.
* .github/workflows/NotifyTracking.yml: New workflow sending a
repository_dispatch to uutils/coreutils-tracking once 'GnuTests' or
'make' has finished on the default branch.
The tracking repository polled our artifacts on a cron, so its graphs
lagged the data by up to six hours. Telling it when the data is ready
lets it refresh immediately; its schedule stays as a safety net.
A GITHUB_TOKEN only covers the repository it runs in, so this needs a
credential of its own: an organization-owned GitHub App installed on the
tracking repository, read from the TRACKING_APP_ID and
TRACKING_APP_PRIVATE_KEY secrets. Without them the step warns and the
tracking repository keeps refreshing on its own schedule.
Sylvestre Ledru