how to use git commands inside a Multi Branch Project?

[Torsten Reinhard]

Hi all,

I have a Multi Branch Project, using a *.git Repository. All branches are detected and the checkout is working.
In my JenkinsFile I need to execute some "git" commands, like:

...
sh "git tag -d FOR_INTEGRATION_TESTING"                     // removes the tag in local env.
sh "git push origin :refs/tags/FOR_INTEGRATION_TESTING"        // removes the tag in remote env.
sh "git tag -a FOR_INTEGRATION_TESTING"                        // adds the tag to different commit
sh "git push origin FOR_INTEGRATION_TESTING"                // pushes the change to the remote
...


How can I apply the credentials here ?
When trying

withCredentials [$class: 'UsernamePasswordMultiBinding', credentialsId: git_creds, usernameVariable: 'G_USER', passwordVariable: 'G_PASS'] {
  ...
}

I see this exception:

org.jenkinsci.plugins.credentialsbinding.impl.CredentialNotFoundException: 
Credentials 'a378e16a-3d20-4465-aef1-b2bd233f15b6' is of type 'SSH Username with private key' 
where 'com.cloudbees.plugins.credentials.common.StandardUsernamePasswordCredentials' was expected

Is there another class instead of "UsernamePasswordMultiBinding" I have to use?

Thanx for pointing me in the right direction,

Torsten

[Torsten Reinhard]

See also http://stackoverflow.com/questions/39237910/jenkins-pipeline-cannot-check-code-into-git
- but there´s no real answer, just workarounds using ssh-agent - or a different protocol with user/password.

So still the question: Any idea how to setup this in a straight-forward manner ?

[Mark Waite]

There isn't a straight-forward way to define a pipeline job such that you can perform arbitrary git commands using a credential.

That seems like it would require one or more extensions to the git plugin.

The alternatives described in the stackoverflow article can be used, each with their own strengths and weaknesses.  None of them are elegant enough to be called "straight-forward".

Mark Waite

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/493ec847-06ac-486d-befb-26c9d9496b92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Shiamak]

There is a plugins

https://wiki.jenkins-ci.org/display/JENKINS/Multi-Branch+Project+Plugin

[Stephen Connolly]

So ideally I'd recommend using ssh-agent, though you may in that case need to force the checkout credentials to be ssh variant to have consistent behaviour.

And you may want to ensure that your pipeline doesn't go commit on anything other than blessed branches... keep in mind PRs will have access to the ssh-agent unless you use the trusted override for the origin jenkinsfile (which means you may not get PR validation of Jenkinsfile changes)

(There is some philosophical differences in how multi-branch should work with various trust constraints... my view is that the job should be able to define rules that get applied to untrusted branches... jesse's view is that the target branch's jenkinsfile should apply the rules and use trusted revision feature to ensure that untrusted branches cannot supply their own jenkinsfile... there are swings and roundabouts in this, no one answer is correct... pipeline follows jesse's thinking ATM)

So anyway, using ssh-agent to wrap the git commits is probably best... certainly reduces the boilerplate. (Downside is getting ssh-agent to work on all build nodes)

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/493ec847-06ac-486d-befb-26c9d9496b92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Sent from my phone

[Michael Kobit]

We haven't really figured both this Git issue yet, but another problem we ran into when running builds in Docker containers is described in https://go.cloudbees.com/docs/support-kb-articles/CloudBees-Jenkins-Enterprise/Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-.html where the socket path is too long.

[Christian Baumann]

Hi all,

I know this topic is rather old, but I´m facing the very same issue and was not able to find a proper solution.

Has anything changed since this question has been raised and someone could provide an answer?

Many thanks,

Christian

Am Mittwoch, 30. November 2016 12:20:22 UTC+1 schrieb Torsten Reinhard:

[Gianluca]

Hi Christian,

I'm doing it in a pipeline that runs various git commands to check out, push and open PRs automatically for some DevOps.

This is how I did:

I've created a bash script git_password_helper.sh with the following content:

#!/bin/sh

exec echo "$GITHUB_PSW"

The in the pipeline, I set the environment to use the GitHub credentials I need:

environment {
	GITHUB = credentials('user_github_token')
	}

I use the personal access token instead of user password because it works and it's more secure than storing password on Jenkins credentials.

Then, I have a bash script containing all the git commands I have to run and the trick is to set GIT_ASKPASS to the bash script above:

export GIT_ASKPASS=./scripts/git_password_helper.sh

git ...
git ...
git ...

How does it works?

The pipeline injects into environment variable GITHUB_USR/PWD the user and access token and they are available to the bash script running the git command, then the GIT_ASKPASS instructs git to call the git_password_helper.sh when it needs the user's password instead of prompting ... and the git_password_helper.sh echo the GITHUB_PWD containing the access token stored into Jenkins credentials.

That works for me.

Cheers,

Gianluca.