Add option to fork default branch only

[Alaurant]

Description

Fixes #1993 , based on Repository create a fork API

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".

[Alaurant]

I've run into a testing issue with GHRepositoryForkBuilderTest. The tests are failing when using the personal account because the mock server can't handle branch API requests.

Here's the error:

Http Server returned HTTP response code: -1, message: 'null' for URL: http://localhost:xxxxx/repos/Alaurant/test-repo/branches

I've seen a similar issue before with owner validation. After removing that check, this error appeared instead. Now I can either skip the branch validation (but then we won't properly test the defaultBranchOnly feature) or add mock responses for my account (which seems like an awkward solution).

I noticed in the docs that using hub4j-test-org is the recommended way to run tests. Could I get access to that organization? This seems like it would solve the problem and follow the project's testing guidelines.

Let me know if there are other approaches I should consider.

Thanks for your guidance!

[bitwiseman]

Invite sent.
What version of Java are you using?

[codecov]

Codecov Report

Attention: Patch coverage is 97.72727% with 1 line in your changes missing coverage. Please review.

Project coverage is 83.56%. Comparing base (4f505a5) to head (4f5e7ff).

Files with missing lines	Patch %	Lines
src/main/java/org/kohsuke/github/GHRepository.java	66.66%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #1995      +/-   ##
============================================
+ Coverage     83.23%   83.56%   +0.32%     
- Complexity     2352     2373      +21     
============================================
  Files           233      234       +1     
  Lines          7225     7245      +20     
  Branches        379      382       +3     
============================================
+ Hits           6014     6054      +40     
+ Misses          973      956      -17     
+ Partials        238      235       -3     

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

[Alaurant]

I'm struggling to get full test coverage on GHRepositoryForkBuilder. The tricky part is testing the timeout logic in create(). Since we're dealing with async fork creation that depends on GitHub's API, I can't find a solid way to trigger and test timeout scenarios.

Here's what Codecov is showing:

Any suggestions on how to test this part of the code would be appreciated.

[bitwiseman]

You're doing great with this PR. I like the builder and you have working tests, you're most of the way there. Thanks for sticking with it!

Regarding code coverage:

First, you can make createTimeoutMessage package private instead of private. Then you can call it from the test methods and test it without making actual REST API calls.

Second, to get line 92 and 94, you're going to need to:

1. Make the sleep interval a package private static field.
2. Make a copy of the successful fork test (including the JSON files) and call it timeoutTest.
3. The first action of the timeout test will be to set the sleep inter to 100 milliseconds. The last action will be to set it back to 3000. This keeps the test from taking a long time.
4. Manually modify the json files so that the request for the forked repo returns 404 and the body of from a "repo not found" test, instead of 200 and a valid repo body. This should require only two JSON files change.
5. The test should catch the exception and verify it is the correct type and expected message.

Does this make sense?

[gounthar]

I have the same kind of problems in #1994.

[bitwiseman]

@gounthar @Alaurant
I did not realize you two were working on the same issue. Sorry.

[gounthar]

No problem, @Alaurant knows your codebase much better than I do.
As long as someone implements the feature, I'm fine with it.

[bitwiseman]

@gounthar
Can you implement the test coverage? I've invited you to the hub4j-test-org.

[Alaurant]

No worries. I had discussed this with @gounthar earlier and offered to help with the implementation. Just for providing another option to get this done.