Fix GHFileNotFoundException when getting commits from PR found in search

[NlightNFotis]

Description

Fixes #1778.

The issue summarily was that a compensation mechanism for sourcing a URL for a query was generating the wrong URL, that was then being used by other parts of the library to create further queries that the Github API would then reject.

This fixes the issue by doing a string search and replace after the string has been first sourced. It has been observed locally that this is an effective fix for the issue described.

Please consider the above a proposed change. If the project maintainers think that this is not an appropriate fix, I'm happy to rework this (if minor changes are needed) or close the PR (if major changes are needed, that are better to be done by someone more familiar with the codebase than myself).

Thank you,

Before submitting a PR:

• Changes must not break binary backwards compatibility. If you are unclear on how to make the change you think is needed while maintaining backward compatibility, CONTRIBUTING.md for details.
• Add JavaDocs and other comments explaining the behavior.
• When adding or updating methods that fetch entities, add @link JavaDoc entries to the relevant documentation on https://docs.github.com/en/rest .
• Add tests that cover any added or changed code. This generally requires capturing snapshot test data. See CONTRIBUTING.md for details.
• Run mvn -D enable-ci clean install site locally. If this command doesn't succeed, your change will not pass CI.
• Push your changes to a branch other than main. You will create your PR from that branch.

When creating a PR:

• Fill in the "Description" above with clear summary of the changes. This includes:
  • If this PR fixes one or more issues, include "Fixes #" lines for each issue.
  • Provide links to relevant documentation on https://docs.github.com/en/rest where possible. If not including links, explain why not.
• All lines of new code should be covered by tests as reported by code coverage. Any lines that are not covered must have PR comments explaining why they cannot be covered. For example, "Reaching this particular exception is hard and is not a particular common scenario."
• Enable "Allow edits from maintainers".

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (5b30e46) 80.44% compared to head (235c281) 80.64%.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #1779      +/-   ##
============================================
+ Coverage     80.44%   80.64%   +0.20%     
- Complexity     2316     2322       +6     
============================================
  Files           219      219              
  Lines          7026     7027       +1     
  Branches        371      371              
============================================
+ Hits           5652     5667      +15     
+ Misses         1141     1128      -13     
+ Partials        233      232       -1     

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

[bitwiseman]

Looks good to me and has test coverage. Thanks!

[daniel-b2c2]

I think this issue might still linger? I can't retrieve getMergeableState from GHPullRequest which appears to be calling https://api.github.com/repos/owner/repo/issues/10312 I don't think this is correct. The API endpoint should be /pulls/

[bitwiseman]

Please provide details. Maybe sample code that reproduces this. Are you on the most recent version.

[daniel-b2c2]

Sure, thanks for taking the time to look, see below:

pom.xml showing latest version:

        <dependency>
            <groupId>org.kohsuke</groupId>
            <artifactId>github-api</artifactId>
            <version>1.319</version>
        </dependency>

Main body of code to demonstrate issue

        GHRepository repository = github.getRepository("company/repo");
        GHPullRequestSearchBuilder query = repository.searchPullRequests();
        PagedSearchIterable<GHPullRequest> list = query.isOpen().list();
        GHPullRequest candidatePullRequests = list.toList().get(0);
        candidatePullRequests.getMergeable();
        String mergeableState = candidatePullRequests.getMergeableState(); // see screenshots for call sequence to incorrect URI
        System.out.println(mergeableState); //this should always be something, maybe 'unknown' or others, but never null

See how the mergeableState is calling the issues api when it should be the pulls api.

Further proof: If you override the value of URI (to point to the pull api) at that breakpoint you can actually trick it into retrieving the expected result and populating the object correctly.

[gsmet]

Yeah, the problem is that we are using getUrl() in refresh() and as demonstrated in getApiRoute(), it's not safe for pull requests.

My understanding is that we should use getApiRoute() instead.

[daniel-b2c2]

So the pattern of using refresh() is fine, it's just the usage of getUrl, should be replaced with getApiRoute?

Unclear if that shadowcat preview is still required.

[gsmet]

Yes, that's what I would do. Would you be able to prepare a PR? Ideally with a test case?

[gsmet]

@daniel-b2c2 I created #1810 to fix it. Thanks for providing all the details.