chmodin windows so the the script will have default permission.
I think we'd need a sample key/password. The issue sounds like it's that the key is encrypted - we'd need to add a seperate utility class for doing the decryption and recovering the key spec for translation. Regards, David
credential.helperis set to
cacheon the system, as mentioned here.
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.