Unable to run on Jenkins

[kreck]

I prefer using Jenkins instead of Travis but i am unable to get semantic-release running on the Jenkins Server.

This the error thrown when running on Jenkins:

semantic-release ERR! commits This means semantic-release can not extract the commits between now and then.
semantic-release ERR! commits This is usually caused by force pushing, releasing from an unrelated branch, or using an already existing package name.
semantic-release ERR! commits You can recover from this error by publishing manually or restoring the commit "4ee416bb0a1e21d43cae4b04314e788041624577".
semantic-release ERR! commits Here is a list of branches that still contain the commit in question: 
semantic-release ERR! commits  * * (detached from 4ee416b)
semantic-release ERR! pre Failed to determine new version.
semantic-release ERR! pre ENOTINHISTORY Commit not in history

It does however run locally on my machine without any problem.

Things i tried:

• completely wipe workspace on Jenkins (no change, problem persists)
• make sure Jenkins prunes and does a fresh (full) clone on every build (no change, problem persists)
• try local "manual" semantic-release on another machine (works just fine)

I'd be glad for any hints that point me in the right direction....

[zakhenry]

@kreck the issue arises from the fact that jenkins checks out the head commit directly and the tree is in a "detatched HEAD state". You can resolve this in jenkins by just running git checkout master or whatever your branch is. Ideally semantic-release would be able to handle detached HEADs however, so this should not resolve this issue, just add clarity

[kreck]

@zakhenry you saved my Friday evening. It is working. Thank you very much!

[janppires]

Hi @kreck! Could you share your semantic-release configuration integrated with jenkins? I do not find enough information about that. Many thanks

[kreck]

@janppires Sure, first you add the relevant tokens (GiHub/npm) to the credentials keychain in Jenkins. Then you simply set up a build task (in my case triggered via GitHub Webhooks). Make sure node is available in your PATH and simply run a "Shell" build script:

git checkout master
set +x
export NPM_TOKEN=${NPM_TOKEN}
export GH_TOKEN=${GH_TOKEN}
set -x
npm prune
npm install
npm run cover
npm run check-coverage
npm run build
npm run semantic-release

Hope that helps....

[janppires]

Thanks @kreck ! That seems easy!

Another problem I have is the fact that I do not want to use the default npm repo. I need to figure out how to setup artifactory instead.

[zot24]

Hi guys! what about the verifyConditions? I'm getting the following:

semantic-release WARN pre semantic-release didn't run on Travis CI and therefore a new version won't be published.
semantic-release WARN pre You can customize this behavior using "verifyConditions" plugins: git.io/sr-plugins

And can make it work on Jenkins I have found this https://github.com/krux/condition-jenkins but not sure if it will be needed/required

Thanks,

[zot24]

We kind of fix part of the problem using the project mention before and adding this to our package.json

"release": {
   "branch": "master",
   "verifyConditions": {
     "path": "./node_modules/@krux/condition-jenkins"
   }
 }

And our Jenkins command that will run the semantic-release pre looks like:

 sh "docker run -v \$(pwd):/data -w /data -e GIT_BRANCH=\"origin/master\" -e JENKINS_URL=${env.JENKINS_URL} -e GH_TOKEN=$GH_TOKEN -e CI=true -e NPM_TOKEN=\"$NPM_TOKEN\" zot24/semantic-release semantic-release pre"

However still getting an error this time a different one

semantic-release ERR! pre The header content contains invalid characters TypeError: The header content contains invalid characters

Any ideas?

Thanks,

[zot24]

It's have to be something related with how Jenkisfile process the commands, some kind of encoding error I think because the command it self works perfectly if you run it manually from the shell either local or from the Jenkins server host

[zot24]

Problem solve it behaved different because the way I was getting the token on the Jenkinsfile was different that when I execute the command from the host, check for more info npm/npm-registry-client#159 ta

If it does helps someone this is how our Jenkinsfile looks like https://github.com/moltin/js-sdk/blob/master/Jenkinsfile

[pvdlg]

Closing as the problem seems to be solved. Please reopen if it's not the case