Jenkins release fails mercurial authentication

Question

I'm trying to release a maven project using Jenkins release plugin and I have a lot of doubts about it.

To load the project into the workspace I'm using an ssh connection since the code is hosted on Bitbucket, I've added a private key to the Jenkins credentials plugin and I had no problem pulling the code.

The problem comes when it tries to create the tags in mercurial and change the pom version, is not being able to authenticate to the mercurial repository. From what I understand is not using the same credentials that when it does the pull. I get push failed with exit code: 255

Ia have the scm connections defined in the pom.xml

<scm>
    <connection>scm:hg:ssh://hg@bitbucket.org/test/test_repo</connection>
    <developerConnection>scm:hg:ssh://hg@bitbucket.org/test/test_repo</developerConnection>
    <url>https://bitbucket.org/test/test_repo</url>
</scm>

How should I define the credentials in jenkins for it to use them to push the changes?

Is there some way to avoid altogether defining the connections in the pom.xml and use the same connection that is using to retrieve the code?

Answer 1

Is there some way to avoid altogether defining the connections in the pom.xml and use the same connection that is using to retrieve the code?

No, credentials used by the Jenkins Mercurial plugin to clone or update the repository are not available to the build in any form thereafter.

You could use the Credentials Binding plugin to expose your private key (as a “file secret”) for the duration of the build, with the location given as an environment variable. I am not then sure how you get maven-release-plugin to include -i $… in ssh commands it runs via git. If you are not tied to private-key authentication, it would probably be easier to use Credentials Binding with username/password credentials, then pass -Dpassword=$… to your Maven release build.

But the usual answer, as Externalising SCM credentials with Maven and other non-Jenkins-specific questions would show, is to use <server> in your ~/.m2/settings.xml. You could of course make sure the Jenkins slave has this file predefined. More manageably and (perhaps) securely, you could use the Config File Provider plugin to pass a custom settings file to your build, with your desired credentials injected.