Mark Waite the "program" might want to fetch dependencies AND push a release tag, as an example, all in the same time. You don't get to know that from your Jenkinsfile. In the Jenkinsfile it is a single step.

It's all quite simple actually - the new bindings could accept multiple pairs url:credential-id which would render into a config file like this:

[credential "https://github.com"]
	useHttpPath = true
	helper = ...
[credential "https://gitlab.com"]
	useHttpPath = true
	helper = ...

And the helper then would look into both host AND path in the input (which the latter would only be available when useHttpPath = true) to match with a UsernamePasswordCredentials instance.

Dee Kryvenko since the withCredentials step provides the credential to all git operations inside the sh, bat, or powershell step, I would expect it to be well behaved whether the program that called git was make, maven, gradle, bazel, or any other tool. I think your scenario of mapping different credentials to individual repositories sounds like a more challenging use case than I'm ready to solve using the withCredentials technique.

Mark Waite - you are assuming entire pipeline is a Jenkinsfile. That is far from being even in majority of the cases. In reality - Jenkinsfile delegates to the tools such as Make/Maven/Gradle/NPM/Terraform/etc. User-supplied untrusted code should be able to safely access only what's it allowed to - write to the current repository and read other repositories as dependencies. From the Jenkinsfile level - we don't have exposure into what is going to happen in the user-supplied code. To enable this workflow - we need to pass in to the tool several sets of credentials. And it might be even more complicated as there could be several locations such as GitHub Orgs in play with different sets of credentials each - or even entirely different providers (GitHub+GitLab for example).

Dee Kryvenko couldn't you achieve the same result by having a single credential that is used for read access to all repositories and an additional credential that allows read/write access to the one repository that needs to be written? Read operations (like fetch and clone) would be performed inside a withCredentials block using the read credentials, then a separate withCredentials block would be used to perform the write operations.

New gitUsernamePassword binding only accounts for a single set of credentials.

Often there are different set of credentials required for different git locations.

Examples would be Go Modules, Terraform Modules and other that are using Git for dependency management. If the current repository we are building have dependencies on other repositories - we need read-write git credentials to the current repository (so we could publish tags, for example) while we need read-only set of credentials to everything else for fetching dependencies.

If this binding currently implemented as AskPass helper - an easy fix would be to accept additional parameter in the binding that'd tell the location the binding is for.