mirror of
https://github.com/wolfSSL/wolfssl.git
synced 2026-08-21 23:03:28 +02:00
Tobias Frauenschläger
91769d99f6
The ccache that keeps this workflow fast is written only by the weekday seed job, which runs on a schedule against the default branch. Nothing had seeded it since 2026-07-24, because the workflow itself was failing to load for that whole stretch, and the Actions cache evicts entries untouched for seven days. The first run after the fix therefore reported "Cache not found for input keys" on all four shards. That cold run measured ~102 thread-minutes per shard, or 24-27 minutes of wall including checkout, deps and autogen, against a 30 minute timeout. Three minutes of headroom on the slowest shard is not enough, and a shard killed by the timeout presents as a test failure rather than as a cold cache. Raise it to 40. The comment above it claimed ~68 thread-minutes and ~20 minutes of wall, which the measurement above contradicts, so replace it with the measured figures. macOS and Windows are left alone: they came in at 11.6 minutes against 45 and 2.0 against 6. Add workflow_dispatch so the seed can be run on demand rather than waiting up to a day for the next cron, which matters exactly in the situation above, where every PR run stays cold until something refills the cache. Adding the trigger alone would not have been enough. The seed behaviour hangs off `github.event_name == 'schedule'` in five places (CCACHE_RECACHE, --build-only on linux and macOS, the cache save, and skipping the Windows job), so a manual run would have gone through the full test path and saved nothing. All five now treat a dispatch as a seed as well. The condition is written against `github.event.inputs.seed` rather than `inputs.seed`, because the `inputs` context is only documented as available on workflow_dispatch and workflow_call, whereas `github.event` always exists. That yields strings, so it is compared explicitly rather than for truthiness, where the string 'false' would read as true. It tests `!= 'false'` and not `== 'true'` so that a dispatch which sends no input at all still seeds: a declared default is not reliably reflected into `github.event.inputs`, and keying on the positive would have made `gh workflow run` quietly skip the seeding it was invoked to do. Comments are brought in line with all of this, including one that was already wrong before the trigger existed: the macOS ccache step is read-only purely on pull_request, so every non-PR run writes that cache, where the note claimed only the seed did. The two platforms seed differently in a second way as well - linux sets CCACHE_RECACHE and so rebuilds from scratch, macOS never does and only accumulates deltas. Neither behaviour is changed here, but both are now written down at the top of the file rather than left to be rediscovered from a surprising cache.