git fetch --allthen it will work even if not using git credential binding, I missed this case since I was not storing my credentials.
@arpoch the git plugin has always assumed that cached credentials were not enabled on the agent. If a user enables credential caching on an agent, they do so at their own risk. I think it is enough to document that assumption without taking active measures to disable cached credentials.
Jenkins users are very creative. I would not want to actively disable credential caching because I fear it would break some existing configurations where users intentionally enabled credential caching and rely on it.
Agent information latency (repository on disc during the build, credentials on disc during the build, repository left after the build, job configuration left after the build, etc.) happens with Jenkins as soon as someone allows themselves to reuse an agent or allows more than one job to run on the same agent concurrently.
JENKINS-28335-freestyle-parameterized-credential-binding, I found that the
buildWrapperswas already expanded, your parameter name was
MY_USERNAME_PASSWORD_CREDENTIAL, but the credentialsId was given as
MarkEWaite-github-token-2019-05-25, should not it be
Set Username as secretcheckbox that we can set to hide the username while selecting credentials, is handled as a string in credential binding plugin here-https://github.com/jenkinsci/credentials-binding-plugin/blob/b6250417116ead0f4079b4c5759fbc7151d29933/src/main/java/org/jenkinsci/plugins/credentialsbinding/impl/UsernamePasswordMultiBinding.java#L77
Secretas I thought.
git username passwordbinding on an Ubuntu agent using ssh and windows as a controller, and I got some unexpected result , the script created to carry out git auth operation is alway created in windows even if the agent is linux based.
git lfsis no longer available on the agents connected to ci.jenkins.io. It will likely be Monday before we're able to identify the issue and resolve it. We may need to disable the LFS tests in the git client plugin or make them conditional on the existence of the
git lfscommand so that we don't delay @arpoch with failing tests that are related to infrastructure
@arpoch @MarkEWaite @justinharringa:matrix.org I have a doubt related to our decision of performing the binding on the git client plugin, instead of Git Plugin. (Sorry for doing this at this stage)
context: As I was looking more into how the Git Plugin resolves a git tool in a multiple nodes/different environment scenario, I can see that the Git Plugin is responsible for interacting with a
Run instance, that is, the git plugin is the place where a Jenkins job interacts with the git apis. We get the git apis from the git client plugin, it works as a utility plugin for the git plugin. The git plugin is supposed to be responsible for working with the Jenkins build and it has various utilities to handle git tool resolution or any other situation where we need to extract such information from the running Jenkins context.
doubt: I am in no way suggesting to shift the implementation at this stage but I can see that we already have a way to resolve a git tool on nodes in the git plugin, I suspect we need to replicate the same in the git client plugin (which, technically, should be unaware of what happens with the Jenkins context).
The reason why we don't have git tool resolution at the git client plugin reconfirms the fact that it is not supposed to work with the Jenkins build/instance.
isAtleastVersionmethod has package-private scope, keeping this in mind I have not made any commits for the ssh binding yet.
resolveGitToolmethod resolves/finds Git Tool by name. So if using
resolveGitToolfor our specific use case then the gitTool name used will be
Defaultas we are not taking any input from the user regarding the git Tool Name so we can't make any assumptions on what name the user will set for the git tool thus we can't supply the gitTool name for
resolveGitToolmethod which comes down to using
gitToolNameis type specific, which only matches the type with the type of tool required irrespective of name set by the user. Both the implementation
gitToolNameare somewhat same only differs in the approach of the find the git tool. Also the time complexity of both the impl will be linear once the
forNodemethod used in the
gitToolNamemethod is removed since it's not required their. So I think it's better to make a separate method in git plugin under
GitUtilsclass which resolves the git Tool name based on the type rather than name.
CliGitAPIImplclass and it seem reasonable as well since it is exclusively for cli git, also I have not added any additional test case but updated the existing
assertVersionOutputmethod to check the
compareLeastGitVersionmethod as well.
Looking forward to the git credentials binding project office hours in about 30 minutes. I've spent an hour or two testing the most recent build and have good results to share.
gitToolName, Pipeline and Freestyle jobs are working great in all the tests that I have run
gitToolName, the job fails (Freestyle and Pipeline)
Great work @arpoch !