[JENKINS-74796] Avoid unauthenticated clone requests

[jenkins-infra-bot]

The normal workflow for git with http/https URLs is to first try to access the URL unauthenticated and only send credentials after that requests was denied with a 401 HTTP response. This might interact badly with git host rate limiting (see, for example https://gitlab.com/gitlab-org/gitlab/-/merge_requests/147112 in GitLab) or even external rate-limiting in WAFs.

Git acquired a new option (http.proactiveAuth) in v2.46.0, which avoids this step. It would be nice if Jenkins could set this flag on clone/fetch operations.

For reference: This is something that actually happened to me: Multiple CI jobs (mixed GitLab Runner & Jenkins CI nodes) were running on the same k8s node and their combined Git requests triggered a rate-limit of that IP in GitLab

---

Originally reported by tgr, imported from: Avoid unauthenticated clone requests

• status: Open
• priority: Minor
• component(s): git-client-plugin
• resolution: Unresolved
• votes: 0
• watchers: 2
• imported: 20251211-071809

Raw content of original issue

The normal workflow for git with http/https URLs is to first try to access the URL unauthenticated and only send credentials after that requests was denied with a 401 HTTP response. This might interact badly with git host rate limiting (see, for example https://gitlab.com/gitlab-org/gitlab/-/merge_requests/147112 in GitLab) or even external rate-limiting in WAFs.

Git acquired a new option (http.proactiveAuth) in v2.46.0, which avoids this step. It would be nice if Jenkins could set this flag on clone/fetch operations.

For reference: This is something that actually happened to me: Multiple CI jobs (mixed GitLab Runner & Jenkins CI nodes) were running on the same k8s node and their combined Git requests triggered a rate-limit of that IP in GitLab

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  Can you set that option globally on your agents already through the global configuration file of the user that is running the Jenkins agent?
  
  That option seems like it will provide benefit, but will move the rate limiting barrier to a higher location rather than managing the requests to stay below the rate limiting barrier.  The branch source plugins (GitHub, GitLab, Bitbucket, ...) include rate limiting in their implementations.  The git plugin does not include any rate limiting.  It would be a large effort to include rate limiting in the git plugin, but might be more globally applicable.
  

Can you set that option globally on your agents already through the global configuration file of the user that is running the Jenkins agent?

That option seems like it will provide benefit, but will move the rate limiting barrier to a higher location rather than managing the requests to stay below the rate limiting barrier. The branch source plugins (GitHub, GitLab, Bitbucket, ...) include rate limiting in their implementations. The git plugin does not include any rate limiting. It would be a large effort to include rate limiting in the git plugin, but might be more globally applicable.