For the CliGitAPIImpl only a single change would have to be made to the launchCommandWithCredentials method (https://github.com/jenkinsci/git-client-plugin/blob/master/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L2082)
Currently it differentiates between SSHUserPrivateKey and StandardUsernamePasswordCredentials. A third branch would be needed to handle what is referred to as Secret Text in the Jenkins UI (probabaly StringCredentials).
As the args is list already in scope in the method we would only need to append the -c extraHeader=.... argument to it and would be good to go.
There is an alternative way to set the extra header through environment vars for new git version >=2.31, see: https://github.com/jenkinsci/bitbucket-branch-source-plugin/issues/716#issuecomment-1579002395
This would lessen the risk of exposing bearer tokens through e.g. the process list on multi user system setups
For the CliGitAPIImpl only a single change would have to be made to the launchCommandWithCredentials method (https://github.com/jenkinsci/git-client-plugin/blob/master/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L2082)
Currently it differentiates between SSHUserPrivateKey and StandardUsernamePasswordCredentials. A third branch would be needed to handle what is referred to as Secret Text in the Jenkins UI (probabaly StringCredentials).
As the args is list already in scope in the method we would only need to append the -c extraHeader=.... argument to it and would be good to go.
There is an alternative way to set the extra header through environment vars for new git version >=2.31, see: https://github.com/jenkinsci/bitbucket-branch-source-plugin/issues/716#issuecomment-1579002395
This would lessen the risk of exposing bearer tokens through e.g. the process list on multi user system setups