Take redirections into account in UrlChecker

[danicheg]

This PR aims to increase the likelihood of URLs (such as those related to release notes) being propagated into PR descriptions. In #3583, I noticed that we omit URLs in the description of the final PR when facing redirections on GitHub, GitLab, etc. While it may seem that the current PR supersedes the mentioned one, I’m confident it does not — and here’s why.

❯ curl -I http://github.com/lettuce-io/lettuce-core/releases/tag/6.5.3.RELEASE
HTTP/1.1 301 Moved Permanently
Content-Length: 0
Location: https://github.com/lettuce-io/lettuce-core/releases/tag/6.5.3.RELEASE

❯ curl -I https://github.com/lettuce-io/lettuce-core/releases/tag/6.5.3.RELEASE
HTTP/2 301
server: GitHub.com
location: https://github.com/redis/lettuce/releases/tag/6.5.3.RELEASE

In the first request, we simply received a tweak to the URL’s Scheme (http->https). In the second request, however, we encountered an actual redirection to the existing resource. FWIW, an attentive reader may notice that these two redirections are handled by different middleware (HTTP/1.1 vs HTTP/2).

As always, I'm open to any concerns or suggestions to help drive this to merge.

[codecov]

Codecov Report

Attention: Patch coverage is 77.77778% with 6 lines in your changes missing coverage. Please review.

Project coverage is 89.75%. Comparing base (1e8e1ea) to head (6ee6639).

Files with missing lines	Patch %	Lines
.../org/scalasteward/core/nurture/UpdateInfoUrl.scala	0.00%	4 Missing ⚠️
...calasteward/core/nurture/UpdateInfoUrlFinder.scala	87.50%	1 Missing ⚠️
.../scala/org/scalasteward/core/util/UrlChecker.scala	91.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3586      +/-   ##
==========================================
- Coverage   89.80%   89.75%   -0.05%     
==========================================
  Files         174      174              
  Lines        5031     5068      +37     
  Branches      445      502      +57     
==========================================
+ Hits         4518     4549      +31     
- Misses        513      519       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[fthomas]

While it may seem that the current PR supersedes the mentioned one, I’m confident it does not — and here’s why.

How about allowing two recursive calls instead of just one? It should work for the lettuce case then, right?

[danicheg]

How about allowing two recursive calls instead of just one? It should work for the lettuce case then, right?

I think so. But when it comes to recursion, it may promptly become three calls, and so on. IMHO, it is beneficial to sort out these scheme-related things when preparing metadata from Coursier. This might be helpful in other places besides UpdateInfoUrlFinder.

[fthomas]

But when it comes to recursion, it may promptly become three calls, and so on.

Three calls would be okay for me, too. The benefit of allowing two calls is that it "fixes" the lettuce case without modifying the scheme.

IMHO, it is beneficial to sort out these scheme-related things when preparing metadata from Coursier. This might be helpful in other places besides UpdateInfoUrlFinder.

I don't see how it would be beneficial. From my perspective merging this PR with two recursive calls would be better than merging this PR as-is and #3583 because it results in less LOC that needs to be maintained.