lychee: .git suffix should be ignored on GH links
Links like https://github.com/Microsoft/python-language-server.git reported as (404 Not Found: Not Found) while https://github.com/Microsoft/python-language-server is totally fine and GH actually redirects .git links there.
It meters for the cases when lychee detects links in config files and code samples that use such links to install dependencies (for example ruby gems, python stuff).
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 33 (18 by maintainers)
Commits related to this issue
- Strip `.git` suffix from Github URLs (#384) — committed to lycheeverse/lychee by mre 2 years ago
- Strip `.git` suffix from Github URLs (#384) — committed to lycheeverse/lychee by mre 2 years ago
- Strip `.git` suffix from Github URLs (#384) — committed to lycheeverse/lychee by mre 2 years ago
i’m experiencing the same issue - for the moment i added all
.gitlinks to my exclude listThis should be fixed in
masternow. 🎉 Recursion isn’t supported yet, so I’d postpone the discussion about fetching theREADME. Quite honestly, I think it goes a bit too far for a general link checker, but we can revisit this in the future. Thanks everyone for your input. Feel free to open a new issue in case you see any odd behavior.Pushed an update to the
strip-gitbranch. It should work as discussed now. Can you try again?Thanks for the quick turnaround! 🙏
The issue with the failing links is a tricky one: AFAIK the Github API doesn’t allow checking for repo endpoints like issues, releases, or actions. For public repos that’s not an issue, because a simple request will check if it exists. In your case however it’s a private repo, so a normal check returns a 404 and a check with the Github token won’t work either because of the API limitations. What we did before was to assume these things would work if the private repo existed, but a user could disable issues or pull requests on a per-repo basis. Even then, I’d say the best way forward is to revert this stricter check and stay in line with the user expectation of returning a 200 – even though we can’t be 100% sure that’s correct. But the alternative of returning a ton of errors for private repos is worse and most people won’t change the repo settings.
Sounds good?