Conversation
Signed-off-by: Alexa Kreizinger <[email protected]>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review infoConfiguration used: defaults Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughUpdates the Lychee link-checker invocation in the GitHub Actions workflow to pass explicit CLI arguments: expand allowed HTTP status codes (100..=103, 200..=299, 401, 403, 429), enable verbose output, disable progress display, and set the working directory to the workflow root (trailing dot). Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/linkcheck.yaml:
- Line 23: The workflow step using the args string currently targets
'./**/*.mdx' which matches no files; update the glob in that args value (the
string passed to the linkcheck action) to include Markdown files, e.g. replace
'./**/*.mdx' with a glob that matches .md (and optionally .mdx) such as
'./**/*.md' or './**/*.{md,mdx}', keeping the existing --accept flags and other
options intact so link checking runs again.
Signed-off-by: Alexa Kreizinger <[email protected]>
this updates the link checker test to ignore
401,403, and429error codes. (the other values in that argument are part of the link checker's default value.)401and403are ostensibly auth errors, but it seems like some non-auth pages return those statuses as an anti-scraper thing when the check runs--and even if they were genuine401or403errors, those don't indicate a broken link, just something that requires login.429also seems like an anti-scraper defense mechanism. in any case, they're not404errors or other status that indicate a genuine broken link :)Summary by CodeRabbit