[PR] ci(prek): give the prek job four cores, drop the dead lychee cache [magpie]

["potiuk (via GitHub)" <gi...@apache.org>]

potiuk opened a new pull request, #1214:
URL: https://github.com/apache/magpie/pull/1214

   Prompted by a 674s run of this workflow. That particular run turned out to be
   a throttled host rather than anything structural — but looking into it surfaced
   two real things.
   
   ### The prek job goes back to four cores
   
   #1190 moved every job to `ubuntu-slim` on the argument that nothing this
   repository runs in CI is heavy. That holds for ten of the eleven jobs — they
   land between 3s and 99s. It does not hold for `prek`.
   
   prek splits each hook's file list across roughly `cpu_count` invocations, so
   one core runs all ~40 hooks over ~4.9k files strictly serial. Measured:
   
   | runner | `Run prek` step | job total |
   | --- | --- | --- |
   | 4-vCPU `ubuntu-latest` | 131s (#1190's own figure) | — |
   | `ubuntu-slim`, two sampled runs | 183s / 211s | 226s / 280s |
   
   The step is ~80% of the job's wall clock either way, so it is the only number
   worth moving. The trade is three cores against ~60-80s on the job that every
   push and every pull request waits for. #1190's reasoning still applies to the
   other ten jobs, and they stay on `ubuntu-slim`.
   
   One consequence worth calling out: `ubuntu-slim`'s 15-minute container kill
   does not exist on `ubuntu-latest`, and no workflow here sets `timeout-minutes`.
   Moving the job off slim would silently swap that ceiling for the 6-hour
   default, so this adds an explicit `timeout-minutes: 15` — roughly 4x the
   slowest run observed.
   
   ### The lychee cache step cached nothing
   
   `.lychee.toml` sets `offline = true`: the hook resolves in-repo paths and
   `#anchor` fragments and never fetches a URL. There were no results to cache.
   From the run that prompted this:
   
   ```
   Received 185 of 185 (100.0%)    <- restored .lycheecache
   Sent 188 of 188 (100.0%)        <- saved .lycheecache
   ```
   
   And because the key was `cache-lychee-${{ github.sha }}`, every commit wrote a
   fresh entry into the repository's cache budget, evicting the 251 MB prek
   hook-env cache sooner than necessary. The step is removed. Three comments
   claimed external-URL results were cached for 7 days — in the workflow, in
   `.lychee.toml`, and on the lychee hook in `.pre-commit-config.yaml` — and now
   describe what actually happens. Reinstating the step is a small diff if
   `offline` ever goes back off.
   
   ### Note for reviewers
   
   Touching `.pre-commit-config.yaml` busts the prek hook-env cache key. The
   `prek-Linux-` restore-key prefix still restores the previous archive and no
   hook definition changed, so no env is rebuilt from scratch; the next run
   re-uploads the archive once.
   
   ### Deliberately not changed
   
   `GITHUB_TOKEN` on the `Run prek` step is now dead weight — its comment says it
   authenticates lychee's github.com link checks, but under `offline = true`
   lychee makes no requests, and nothing else in the step reads it. Left alone to
   keep this PR to the two changes above; happy to drop it separately.
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   
   https://claude.ai/code/session_019rmycnoL6JcVWPgpyimD7S
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] ci(prek): give the prek job four cores, drop the dead lychee cache [magpie]

["potiuk (via GitHub)" <gi...@apache.org>]

potiuk merged PR #1214:
URL: https://github.com/apache/magpie/pull/1214


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org