deprecate [tokei] service

[chris48s]

This might be a bit controversial, but..

This service has been out of action for some time. We've tried raising issues upstream with no response. Even when it has been "working", this has been an unreliable service, frequently producing unexpected results for users or not returning a response within a timeframe that allows us to render a useful response. This is unsurprising given it is essentially fetching an upstream repository (which might be very large) and counting the lines of code on-demand. If I pass https://github.com/torvalds/linux as the input, you're just not going to do that in 4 seconds or less, even if you did write the code in rust.

For example:

• Unparseable json response for lines of code badge #6637
• Why my lines of code are 0? #6833
• Total Lines of Code gives HTTP 408 periodically #7889
• total lines (tokei) don't work #8796
• "invalid response data" in total lines #9389
• Lines of code just reports invalid data in the badge #9569

I think it is time to give up on this one.

Closes #7569

[github-actions]

	Messages
📖	✨ Thanks for your contribution to Shields, @chris48s!

Generated by 🚫 dangerJS against acc374b

[calebcartwright]

Let's hold off on this for a bit as the Tokei maintainer has commented on relevant issues earlier today.

In general I'd be in favor of deprecating this service, but only because:

• There's been service availability issues, the maintainer has acknowledged it's a side/passion project they can't spend much time on, and some of the issues that pop up ultimately stem from cost considerations
• This service doesn't necessarily meet our guidelines wrt documentation (the fact that you can get a json response from their badge url via the content header is an undocumented feature), support/maintainer availability, etc.

However, I have to disagree with the performance characteristics portion of the reasoning. IMO this is another canonical example of the "good badge for us, but can be quite slow to respond on the first call" scenario, which is precisely the reasoning behind #9233.

The tokei.rs web service does have caching enabled, so even if the first call for counting all the lines of the linux kernel is slow, the subsequent calls should return well within the window we'd need to satiate camo's timeout limit.

AFAICT the service is working just fine and has been for a while, it's just that the lines field mysteriously disappeared. I've bumped your upstream issue with the maintainer, and if we can get a timely resolution on that (even if it's something to the effect of "that was intentional, just add the code, blanks, and comments fields to get the total moving forward) then I'd be in favor of retaining this badge.

But I'm 👍 with deprecating this if we can't get an answer on that and/or see a recurrence of the availability issues in the future

[chris48s]

Yeah - fair shout. If the other issues can be sorted, we could add an ETIMEDOUT handler for the performance issue 👍

[Naegolus]

We removed all tokei badges from our repositories because they weren't working most of the time.

[PyvesB]

I'd be in favour of removing this badge at this point, it's been broken for months now, latest issue being SSL handshakes with the API.