* .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.
* .github/workflows/GnuTests.yml (env): Add REFERENCE_BRANCH.
(on.push.branches): Exclude the reference branch, which carries no code.
(aggregate): Fetch the reference from that branch rather than resolving
and downloading a workflow artifact.
(publish-reference): New job publishing this run's results on a push to
the default branch.
An artifact is addressable only by run id, so finding one meant listing
workflow runs on the default branch. That listing's 'branch' filter is
served by an eventually consistent index which intermittently returns a
snapshot weeks out of date, making every test fixed on the default
branch since then look like a fix contributed by the pull request.
- Add conditional compilation for WASI target to avoid panics from `std::env::temp_dir()`
- Implement fallback logic in `Options` to read TMPDIR environment variable directly on WASI
- Update `get_tmpdir_env_or_default()` with WASI-specific handling for temp directory resolution
- Add `#[cfg_attr]` annotations to skip host path-dependent tests on WASI sandbox environment
- Ignore 14 tests that require host filesystem access when running under wasi_runner
- Ignore directory permission test on WASI due to lack of `chmod` support and mode parameter limitations
cp treats ENOSYS like EOPNOTSUPP when skipping optional attribute
preservation (WASI has no chmod/chown at all), reads timestamps via
Metadata::accessed/modified instead of the filetime crate (which
panics there), and only errors out of --reflink when explicitly
requested rather than whenever it isn't Never.