Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Take redirections into account in UrlChecker #3586

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

danicheg
Copy link
Contributor

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.

@danicheg danicheg changed the title Take redirect into account in UrlChecker Take redirections into account in UrlChecker Feb 16, 2025
Copy link

codecov bot commented Feb 16, 2025

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
Copy link
Member

fthomas commented Feb 17, 2025

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants