[NoamGoren]

Fixes #799.

GitHubLoginFunction now gives github-api an OkHttpGitHubConnector instead of the deprecated OkHttpConnector. The old connector sends each request through ObsoleteUrlFactory, which clears the OkHttp client's interceptors and network interceptors on every call, so OkHttp instrumentation (the OpenTelemetry Java agent, for example) never saw the plugin's GitHub API calls. github-api recommends this switch (hub4j/github-api#1262) and removes OkHttpConnector in 2.0. GitHub Branch Source gets the same change in jenkinsci/github-branch-source-plugin#1576.

 GitHubLoginFunction.connector(config)
-  new OkHttpConnector(BASECLIENT + proxy + cache)       // per request: client rebuilt, interceptors cleared
+  new OkHttpGitHubConnector(baseClient + proxy + cache) // per request: client.newCall(request).execute()

The new package-private constructor GitHubLoginFunction(OkHttpClient) lets the test pass a client with interceptors. The public constructor still uses BASECLIENT.

Same as before (github-api 1.330, both connectors):

• cacheMaxAge 0, TLS connection specs, Cache-Control: max-age=0 when there is a cache, ETag revalidation from the disk cache
• the Jenkins proxy, timeouts, redirects, gzip, error bodies
• RateLimitHandler.FAIL still fails the request

Changes:

• Client interceptors run. This is the fix.
• The User-Agent header changes from ObsoleteUrlFactory to OkHttp's default (okhttp/4.12.0), because github-api doesn't set one.
• GitHub.getConnector() throws UnsupportedOperationException with this connector, as the github-api 1.300 release notes say. The plugin doesn't call it, and a code search of jenkinsci finds no caller.
• A RuntimeException thrown inside OkHttp is no longer wrapped in an IOException.

Testing done

GitHubLoginFunctionTest is new. For the "before" column, only the connector type was put back to OkHttpConnector:

Test	OkHttpConnector (before)	OkHttpGitHubConnector (after)
requestsGoThroughTheClientInterceptors	fails: both interceptor lists are empty	passes
cachedResponseIsRevalidatedWithETag	passes	passes
rateLimitExceededFails	passes	passes

The last two show that the disk cache and the rate limit handling behave as before. The cache test is skipped on Windows, like GitHubClientCacheCleanupTest, because the open disk cache keeps JENKINS_HOME from being deleted there.

mvn verify, checkstyle included:

• This branch: 320 tests, 0 failures, 1 skipped, on JDK 21.0.8 and on JDK 25.0.5 (macOS).
• master: 317 tests, 0 failures, 1 skipped.

End to end with the OpenTelemetry Java agent 2.33.1 (OkHttp instrumentation only, logging exporter). A JenkinsRule test ran new GitHubLoginFunction().apply(config) against https://api.github.com and called getRepository. It had no stored credentials, so the plugin sent its placeholder token and GitHub answered 401:

before (OkHttpConnector):       no http.client.request.duration points
after  (OkHttpGitHubConnector): io.opentelemetry.okhttp-3.0  api.github.com  GET  401  count=2  (/user, repository)

Manual test: start Jenkins with the agent flags from #799 and click Test connection on a GitHub server in Manage Jenkins > System. The agent's metric output then shows http.client.request.duration for the server's host.

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed

---

This change is 

[NoamGoren]

Also checked with OkHttp 5. This repository's bom resolves okhttp-api 4.12.0-195 (OkHttp 4.12.0), but okhttp-api 5.x is released, and controllers that update it run OkHttp 5. For a local run I pinned okhttp-api 5.3.2-200.vedb_720a_cf1f8 and the jars from its hpi (OkHttp 5.3.2, okio 3.16.4, Kotlin 2.2.21) in dependencyManagement. That override is not part of this PR.

	OkHttpConnector (before)	OkHttpGitHubConnector (after)
GitHubLoginFunctionTest	requestsGoThroughTheClientInterceptors fails ("was empty"), the other two pass	3 passed
OpenTelemetry Java agent 2.33.1, new GitHubLoginFunction().apply(config) against https://api.github.com and getRepository, no stored credentials	no http.client.request.duration points	api.github.com GET 401 ×2

These are the same results as with OkHttp 4.12.0 in the description.

[NoamGoren]

The Windows build failed in the 3 tests that use GitHubMockExtension.serverConfig(): GitHubCommitNotifierTest.shouldWriteStatusOnGH, GitHubCommitStatusSetterTest.shouldSetGHCommitStatus and GitHubSetCommitStatusBuilderTest.shouldLoadNullStatusMessage. JenkinsRule couldn't delete GitHubPlugin.cache/<hash>/journal. The cause is in the tests, not in the change. 7a58f60 fixes them (test only).

Cause

On Windows, JenkinsRule calls URLConnection.setDefaultUseCaches(false). ObsoleteUrlFactory followed that and built each call without the OkHttp cache, so on Windows these tests never used the disk cache. OkHttpGitHubConnector doesn't go through URLConnection, so it uses the cache (20 MB by default), and the open journal keeps JenkinsRule from deleting JENKINS_HOME. GitHubClientCacheCleanupTest is skipped on Windows for the same reason.

Fix

GitHubMockExtension.serverConfig() sets the client cache size to 0 on Windows. Other platforms keep the default.

Checked on macOS with a temporary probe that lists cache journals in JENKINS_HOME after each test:

• Before: exactly these 3 tests leave a journal.
• After, with the Windows branch forced: no test leaves a journal, and all 9 tests in the 3 classes pass.
• Full mvn verify on JDK 21: 320 tests, 0 failures, 1 skipped, 0 Checkstyle violations.

Production behavior is unchanged: Jenkins core doesn't turn the default URL caches off (checked in jenkins-core 2.504.3, 2.541.1 and 2.555.3), so outside tests the old connector used the cache as well.