ci: harden the link check so it fails only on real breakage - #7
Merged
Conversation
Follow-up to the --base . repair. Verified against lychee 0.24.2 locally before pushing this time; all four repos report 0 errors with these exact arguments. - --accept REPLACES lychee's default accept set rather than extending it, so the inherited '--accept 200,206,429' silently made 201/202/204/207/226 count as broken links. Proven with httpbin: a 204 passes by default and is rejected under the old flag. Now restates the default set plus 429. - --accept-timeouts is the purpose-built flag for "fail on broken, tolerate slow". lychee counts a TIMEOUT as an error and exits 2, which is how a run reporting "Errors 0" failed a PR on a slow tauri.app. Confirmed: a lone timeout now exits 0, a 404 still exits 2. - --cache-exclude-status stops a transient 429/5xx being cached as a failure and replayed for 24h, which re-running the job does not clear. - --max-concurrency 32 instead of the default 128 from a single runner IP. - The path filters now include the workflow itself. Omitting it is why --base . shipped and survived three weekly crons: a PR editing only the link check did not run the link check. - The issue step is gated on lychee's own exit code, not on the job failing, so a checkout or 'npm run check' failure can no longer file an issue titled "Broken links found". It also reuses one issue instead of filing a fresh one every failing cron. - package.json still shipped the broken 'lychee --base .' in the linkcheck script; the workflow was fixed in the last pass and the script was not. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to the
--base .repair, with everything verified against lychee 0.24.2 locally before pushing this time. All four repos report 0 errors with these exact arguments.What was still wrong
--acceptreplaces the default accept set201/202/204/207/226counted as broken links--accept 200,206,429Errors 0still failed the PR--accept-timeoutsexits 0, and a 404 still exits 2--cache-exclude-status '429,500..=599'--base .shipped and survived three weekly crons — a PR editing only the link check did not run it.github/workflows/linkcheck.ymlfailure()npm run checkfailure filed an issue titled "Broken links found", with an empty bodyexit_code, and reuses one issue instead of filing a fresh one every cronpackage.jsonstill shippedlychee --base .npm run linkcheckhit the exact error that broke CI for 16 daysAlso
--max-concurrency 32rather than 128 requests from one runner IP, and the four workflows are now generated from one template so they are genuinely identical apart from their excludes.Every exclude carries its reason inline.
docs.*.privacykey.orgis marked to be dropped once DNS exists — those links are dead for readers, not just for CI.