Fixed Lychee cache key

[mnocon]

Target: 5.0, 6.0

Right now, the cache key is based on the contents of the lychee.toml file.

But the file itself will rarely change, which means that almost every job uses the same cache keys.

This results in the cache not being used, even today.

Example:

https://github.com/ibexa/documentation-developer/actions/runs/28787092734

Restore Lychee cache:

Cache hit for: lychee-5.0-635a6ced35b076bb4a27a7ea27fe631803b2361839e32236f526011a6ff5c750
(node:2691) [DEP0169] DeprecationWarning: `url.parse()` behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for `url.parse()` vulnerabilities.
Received 36546 of 36546 (100.0%), 0.3 MBs/sec
Cache Size: ~0 MB (36546 B)
/usr/bin/tar -xf /home/runner/work/_temp/cc866524-901f-4773-b7ed-b90e226bab46/cache.tzst -P -C /home/runner/work/documentation-developer/documentation-developer --use-compress-program unzstd
Cache restored successfully
Cache restored from key: lychee-5.0-635a6ced35b076bb4a27a7ea27fe631803b2361839e32236f526011a6ff5c750

Checking links

  [WARN] Cache is too old (age: 2d 18h 14m 24s, max age: 2d 0h 0m 0s). Discarding and recreating.

After checking links

Cache hit occurred on the primary key lychee-5.0-635a6ced35b076bb4a27a7ea27fe631803b2361839e32236f526011a6ff5c750, not saving cache.

So, the cache right now is too old to be used, it's not overwritten with fresher values (because it's matched on the primary key) - so it will always be stale.
Switching to commit hash allows us to use the cache for some builds, but will make it update every time we commit something new, keeping it fresh.

Self-review done by Claude:

Yes — this is a good change, and arguably fixes a real bug in the old setup.

Why the old key (hashFiles('lychee.toml')) was problematic: lychee.toml rarely changes, so the cache key was effectively constant per branch. GitHub Actions cache entries are immutable once written — a given key can only be saved once. So after the first run created the cache, every subsequent run would get an exact-match hit and restore it, but the post-job save step would then skip saving (since the key already exists). That means .lycheecache would essentially freeze at whatever it was after the first run and never accumulate new results — including this workflow's own daily cron runs, whose whole purpose is to periodically re-check links and refresh cached results.

Why github.sha is the right key here: the cache isn't tied to reproducible input content (like a lockfile hash for npm ci) — it's an accumulating record of link-check results that should grow/update every run. Using github.sha guarantees a unique key per run, so:
- The exact-match cache lookup always misses, falling through to restore-keys (lychee-<branch>- → lychee-), which still restores the most recent previous cache.
- The post-job step always saves a fresh cache under the new sha, so newly checked/cached links persist forward.

This is the standard pattern for caches meant to continuously accumulate (ccache, build caches, etc.) rather than caches keyed to deterministic input (lockfiles). So switching to sha is correct — it fixes the staleness issue and matches the intent of restore-keys already in place.

[github-actions]

Preview of modified files: no change to preview.

[github-actions]

Summary

Status	Count
🔍 Total	758288
🔗 Unique	14992
✅ Successful	7260
⏳ Timeouts	0
🔀 Redirected	0
👻 Excluded	751028
❓ Unknown	0
🚫 Errors	0
⛔ Unsupported	0

Full Github Actions output

[adriendupuis]

This github.sha usage looks like the key from doc https://lychee.cli.rs/continuous-integration/github/#caching (with branch name in the middle for restore-keys).