Disable lychee-action

[ryanplusplus]

The lychee checks have been failing often for gnu.org and now they seem to fail 100% for GitHub links. I tried updating the lychee action with the same result and found an issue that seems to describe a similar issue that is blamed on a dependency of lychee that can't be easily fixed.

It seems like this check has gotten to be more trouble than it's worth. What does everyone think about disabling it? @wolf99 @siebenschlaefer

[wolf99]

The errors for GitHub links look like rate limiting. We could add --cache for that.

[ryanplusplus]

The errors for GitHub links look like rate limiting. We could add --cache for that.

I have been seeing issues on the first run (ie: runs that aren't quickly following another) in addition to subsequent runs. I assume that it's because of requests from other workflows on other repos. I did a quick check to see whether --cache would help us and got rate limited before the first run completed (which makes sense because I think it only helps on subsequent runs):
https://github.com/exercism/c/actions/runs/14841633794/job/41665758426?pr=1052

[ahans]

We could make it a check that does not block merging or allow one to skip it with a comment or tag in the title. Then it would still do its thing and when it flags something it shouldn't, one can still manually check and override when a link is in fact valid.

[ahans]

The errors for GitHub links look like rate limiting. We could add --cache for that.

I have been seeing issues on the first run (ie: runs that aren't quickly following another) in addition to subsequent runs. I assume that it's because of requests from other workflows on other repos. I did a quick check to see whether --cache would help us and got rate limited before the first run completed (which makes sense because I think it only helps on subsequent runs): https://github.com/exercism/c/actions/runs/14841633794/job/41665758426?pr=1052

Did you also include a cache action? AFAIU, GH runners are ephemeral, so whatever a tool caches will not be available to another run, unless extra measures are taken (such as using the cache action).

[ryanplusplus]

Did you also include a cache action? AFAIU, GH runners are ephemeral, so whatever a tool caches will not be available to another run, unless extra measures are taken (such as using the cache action).

I did not, good call. The issue is that these checks are, at this point, never passing so there wouldn't be a successful check to cache.

We could make it a check that does not block merging or allow one to skip it with a comment or tag in the title. Then it would still do its thing and when it flags something it shouldn't, one can still manually check and override when a link is in fact valid.

We could do this, but how much value is there to having a check that always fails with many false positives? I'm skeptical that anyone is going to look through the results to see if any of the 50+ failures are real.

[ryanplusplus]

Bump for this guy -- we're still failing lychee on the first try and everything needs to be merged with failing checks. I'd love to have this working again, but right now it's useless and misleading.

[ahans]

I will try to look into it if I don't forget. Let's disable for now.