I have GitLab Community Edition 8.15.2 successfully trigger pipeline projects in Jenkins 2.32.1 using a webhook. I want the gitlab push to trigger a build with parameters but the parameter value is null when it comes through so the build fails.
The gitlab webhook looks like:
http://jenkins.server:8080/project/project-a/buildWithParameters?MYPARAM=foo
In my pipeline project I echo the parameter value out with
echo "MYPARAM: ${MYPARAM}"
and it's not set to anything. Any ideas on where I've gone wrong?
UPDATE
The actual code I'm using in the pipeline is:
node {
try {
echo "VM_HOST: ${VM_HOST}"
echo "VM_NAME: ${VM_NAME}"
stage('checkout') {
deleteDir()
git 'http://git-server/project/automated-build.git'
}
stage('build') {
bat 'powershell -nologo -file Remove-MyVM.ps1 -VMHostName %VM_HOST% -VMName "%VM_NAME%" -Verbose'
}
...
}
}
The parameter VM_HOST has a default value but VM_NAME doesn't. In my Console output in Jenkins I can see:
[Pipeline] echo
VM_HOST: HyperVHost
[Pipeline] echo
VM_NAME:
I have been struggling with this for weeks. I had it working once, but I couldn't get it to work again, untill today. And the solution was mindblowingly obvious ofcourse...
Automatically for each pipeline job I ticked the following box:
Build when a change is pushed to GitLab. GitLab CI Service URL:
http://jenkins.dev:8080/project/MyProject
Then from GitLab I used the webhook to trigger the above.
Like you I tried to add /buildWithParameters and tried many other things that didn't work.
The problem was, I ticked the wrong checkbox!
Since I trigger the build from a GitLab webhook, the above checkbox (build when a...) does not have to be checked at all.
What needs to be checked is:
Trigger builds remotely (e.g., from scripts)
That checkbox provides you with a new URL:
Use the following URL to trigger build remotely:
JENKINS_URL/job/MyProject/build?token=TOKEN_NAME or
/buildWithParameters?token=TOKEN_NAME
Like all the documentation I came along states and as you can see, the URL now no longer starts with /project, but with /job instead!
So tick that box and change your URL accordingly:
http://jenkins.server:8080/**job**/project-a/buildWithParameters?token=TOKEN_NAME&MYPARAM=foo
Least I want to mention the token:
In the GitLab webhook there is a seperate field for "token", which states:
Use this token to validate received payloads. It will be sent with the request in the X-Gitlab-Token HTTP header.
So, the token provided there will be sent along the request as a HTTP header.
This is the token which can be provided globally in the Jenkins setup.
The token you must provide in the Jenkins job when ticking the box Use the following URL to trigger build remotely must be send in the URL as GET parameter, just like the example shows.
Final note: personally I have never got this working completely, because I don't get the Jenkins CSRF protection off my back. Disabling it gives me another error. However, hopefully the above does fix the problem for you and others.
GitLab plugin does not allow you to pass arbitrary parameters. In their project there is an open issue for it that deserves to be upvoted.
My convoluted solution was to use the desired values for the push trigger as the default parameters of the job. Then I used the Parameterized Scheduler plugin to use other values in the scheduled executions.
The problem is that I got a bad usability for the job when it was manually run, since the default parameters were appropriate for the push hook.
I found the solution here https://www.jittagornp.me/blog/jenkins-gitlab-webhook/
I verified it with Jenkins 2.263.1 and GitLab Community Edition 13.6.1
Your webhook url will look like
https://hunter:11a403302a4f01b9b4975c0ac27441a5cc#jenkinsservername.com/job/yourjenkinsproject/buildWithParameters?token=Aju9ryHUu6t7W8wLSeCWtY2bWjzQduYNPyY7B3gs&yourparam=yourvalue
"hunter" ist your username in Jenkins.
The following is the Jenkins API Token you have to create in your Jenkins User Managment independent of the project.
The last Token is the one you specify in the jenkins project options under "Trigger builds remotely (e.g., from scripts)"
The last thing is to add your Parameter and value to the url with ¶m=value
I'm trying to test out the parallel functionality for a Jenkins pipeline job, but for some reason the individual build steps of the parallel job never get passed off to an executor and processed. Normal single-threaded pipeline jobs have no issue processing. I tried restarting the Jenkins server in case some resources were locked up, but it did not help.
The full script I'm trying to execute is:
def branches = [:]
branches["setup"] = {node("nsetup") {
echo "hello world"
}}
parallel branches
I have only one node, the master, and it has 5 available executors. It is configured to "use as often as possible". I'm pretty new to Jenkins and setting up a server for the first time, so maybe there's something I missed in the configuration that isn't related to the job.
Does anybody have any suggestions?
And 2 minutes after I post I figure it out! Every time.
Turns out I just didn't have any idea how the "node" command really works. By specifying a parameter in the parentheses, it was preventing it from releasing to an executor. I'm guessing that must tell it to try executing on a certain node matched by label, and I was using it like it was some random logging field. Oops!
Our Jenkins server has a job that has been running for three days, but is not doing anything. Clicking the little X in the corner does nothing, and the console output log doesn't show anything either. I've checked on our build servers and the job doesn't actually seem to be running at all.
Is there a way to tell jenkins that the job is "done", by editing some file or lock or something? Since we have a lot of jobs we don't really want to restart the server.
I had also the same problem and fix it via Jenkins Console.
Go to "Manage Jenkins" > "Script Console" and run a script:
Jenkins .instance.getItemByFullName("JobName")
.getBuildByNumber(JobNumber)
.finish(hudson.model.Result.ABORTED, new java.io.IOException("Aborting build"));
You'll have just specify your JobName and JobNumber.
Go to "Manage Jenkins" > "Script Console" to run a script on your server to interrupt the hanging thread.
You can get all the live threads with Thread.getAllStackTraces() and interrupt the one that's hanging.
Thread.getAllStackTraces().keySet().each() {
t -> if (t.getName()=="YOUR THREAD NAME" ) { t.interrupt(); }
}
UPDATE:
The above solution using threads may not work on more recent Jenkins versions. To interrupt frozen pipelines refer to this solution (by alexandru-bantiuc) instead and run:
Jenkins.instance.getItemByFullName("JobName")
.getBuildByNumber(JobNumber)
.finish(
hudson.model.Result.ABORTED,
new java.io.IOException("Aborting build")
);
In case you got a Multibranch Pipeline-job (and you are a Jenkins-admin), use in the Jenkins Script Console this script:
Jenkins.instance
.getItemByFullName("<JOB NAME>")
.getBranch("<BRANCH NAME>")
.getBuildByNumber(<BUILD NUMBER>)
.finish(hudson.model.Result.ABORTED, new java.io.IOException("Aborting build"));
From https://issues.jenkins-ci.org/browse/JENKINS-43020
If you aren't sure what the full name (path) of the job is, you may use the following snippet to list the full name of all items:
Jenkins.instance.getAllItems(AbstractItem.class).each {
println(it.fullName)
};
From https://support.cloudbees.com/hc/en-us/articles/226941767-Groovy-to-list-all-jobs
Without having to use the script console or additional plugins, you can simply abort a build by entering /stop, /term, or /kill after the build URL in your browser.
Quoting verbatim from the above link:
Pipeline jobs can by stopped by sending an HTTP POST request to URL
endpoints of a build.
<BUILD ID URL>/stop - aborts a Pipeline.
<BUILD ID URL>/term - forcibly terminates a build (should only be used if stop does not work.
<BUILD ID URL>/kill - hard kill a pipeline. This is the most destructive way to stop a pipeline and should only be used as a last
resort.
The first proposed solution is pretty close. If you use stop() instead of interrupt() it even kills runaway threads, that run endlessly in a groovy system script. This will kill any build, that runs for a job.
Here is the code:
Thread.getAllStackTraces().keySet().each() {
if (it.name.contains('YOUR JOBNAME')) {
println "Stopping $it.name"
it.stop()
}
}
Once I encounterred a build which could not be stopped by the "Script Console". Finally I solved the problem with these steps:
ssh onto the jenkins server
cd to .jenkins/jobs/<job-name>/builds/
rm -rf <build-number>
restart jenkins
I use the Monitoring Plugin for this task. After the installation of the plugin
Go to Manage Jenkins > Monitoring of Hudson/Jenkins master
Expand the Details of Threads, the small blue link on the right side
Search for the Job Name that is hung
The Thread's name will start like this
Executor #2 for master : executing <your-job-name> #<build-number>
Click the red, round button on the very right in the table of the line your desired job has
If you have an unstoppable Pipeline job, try the following:
Abort the job by clicking the red X next to the build progress bar
Click on "Pause/resume" on the build to pause
Click on "Pause/resume" again to resume the build
Jenkins will realize that the job should be terminated and stops the build
I guess it is too late to answer but my help some people.
Install the monitoring plugin. (http://wiki.jenkins-ci.org/display/JENKINS/Monitoring)
Go to jenkinsUrl/monitoring/nodes
Go to the Threads section at the bottom
Click on the details button on the left of the master
Sort by User time (ms)
Then look at the name of the thread, you will have the name and number of the build
Kill it
I don't have enough reputation to post images sorry.
Hope it can help
The top answer almost worked for me, but I had one major problem: I had a very large number (~100) of zombie jobs due to a particularly poorly-timed Jenkins restart, so manually finding the job name and build number of each and every zombie job and then manually killing them was infeasible. Here's how I automatically found and killed the zombie jobs:
Jenkins.instance.getItemByFullName(multibranchPipelineProjectName).getItems().each { repository->
repository.getItems().each { branch->
branch.builds.each { build->
if (build.getResult().equals(null)) {
build.doKill()
}
}
}
}
This script loops over all builds of all jobs and uses getResult().equals(null) to determine whether or not the job has finished. A build that's in the queue but not yet started will not be iterated over (since that build won't be in job.builds), and a build that's finished already will return something other than null for build.getResult(). A legitimately running job will also have a build result of null, so make sure you have no running jobs that you don't want to kill before running this.
The multiple nested loops are mainly necessary to discover every branch/PR for every repository in a Multibranch Pipeline project; if you're not using Multibranch Pipelines you can just loop over all your jobs directly with something like Jenkins.instance.getItems().each.
Build-timeout Plugin can come handy for such cases. It will kill the job automatically if it takes too long.
I've looked at the Jenkins source and it appears that what I'm trying to do is impossible, because stopping a job appears to be done via a Thread interrupt. I have no idea why the job is hanging though..
Edit:
Possible reasons for unstoppable jobs:
if Jenkins is stuck in an infinite loop, it can never be aborted.
if Jenkins is doing a network or file I/O within the Java VM (such as lengthy file copy or SVN update), it cannot be aborted.
Alexandru Bantiuc's answer worked well for me to stop the build, but my executors were still showing up as busy. I was able clear the busy executor status using the following
server_name_pattern = /your-servers-[1-5]/
jenkins.model.Jenkins.instance.getComputers().each { computer ->
if (computer.getName().find(server_name_pattern)) {
println computer.getName()
execList = computer.getExecutors()
for( exec in execList ) {
busyState = exec.isBusy() ? ' busy' : ' idle'
println '--' + exec.getDisplayName() + busyState
if (exec.isBusy()) {
exec.interrupt()
}
}
}
}
Recently I came across a node/agent which had one executor occupied for days by a build "X" of a pipeline job, although that jobs page claimed build "X" did not exist anymore (discarded after 10 subsequent builds (!), as configured in the pipeline job). Verified that on disk: build "X" was really gone.
The solution: it was the agent/node which wrongly reported that the occupied executor was busy running build "X". Interrupting that executor's thread has immediately released it.
def executor = Jenkins.instance.getNode('NODENAME').computer.executors.find {
it.isBusy() && it.name.contains('JOBNAME')
}
println executor?.name
if (executor?.isBusy()) executor.interrupt()
Other answers considered:
The answer from #cheffe: did not work (see next point, and update below).
The answers with Thread.getAllStackTraces(): no matching thread.
The answer from #levente-holló and all answers with getBuildByNumber(): did not apply as the build wasn't really there anymore!
The answer from #austinfromboston: that came close to my needs, but it would also have nuked any other builds running at the moment.
Update:
I experienced again a similar situation, where a Executor was occupied for days by a (still existing) finished pipeline build. This code snippet was the only working solution.
Had this same issue but there was not stack thread. We deleted the job by using this snippet in the Jenkins Console. Replace jobname and buil dnumber with yours.
def jobname = "Main/FolderName/BuildDefinition"
def buildnum = 6
Jenkins.instance.getItemByFullName(jobname).getBuildByNumber(buildnum).delete();
This works for me everytime:
Thread.getAllStackTraces().keySet().each() {
if (it.name.contains('YOUR JOBNAME')) {
println "Stopping $it.name"
it.stop()
}
}
Thanks to funql.org
I usually use jenkins-cli in such cases. You can download the jar from a page http://your-jenkins-host:PORT/cli . Then run
java -jar jenkins-cli.jar delete-builds name_of_job_to_delete hanging_job_number
Auxiliary info:
You may also pass a range of builds like 350:400.
General help available by running
java -jar jenkins-cli.jar help
Context command help for delete-builds by
java -jar jenkins-cli.jar delete-builds
I had same issue at the last half hour...
Was not able to delete a zombie build running in my multi-branch pipeline.
Even Server restarts by UI or even from commandline via sudo service jenkins restart
did block the execution... The build was not stoppable... It always reapeared.
Used Version: Jenkins ver 2.150.2
I was very annoyed, but... when looking into the log of the build I found something intersting at the end of the log:
The red marked parts are the "frustrating parts"...
As you can see I always wanted to Abort the build from UI but it did not work...
But there is a hyperlink with text Click here to forcibly terminate running steps...(first green one)
Now I pressed the link...)
After the link execution a message about Still paused appeared with another Link Click
here to forcibily kill entire build (second green one)
After pressing this link also the build finally was hard killed...
So this seems to work without any special plugins (except the multibranch-pipeline build plugin itself).
VERY SIMPLE SOLUTION
The reason I was seeing this issue was incorrect http link on the page instead of https that should stop the job. All you need to do is to edit onclick attribute in html page, by following
Open up a console log of the job (pipeline) that got hang
Click whatever is available to kill the job (x icon, "Click here to forcibly terminate running steps" etc) to get "Click here to forcibly kill entire build" link visible (it's NOT gonna be clickable at the moment)
Open the browser's console (use any one of three for chrome: F12; ctrl + shift + i; menu->more tools->developer tools)
Locate "Click here to forcibly kill entire build" link manually or using "select an element in the page" button of the console
Double click on onclick attribute to edit its value
Append s to http to have https
Press enter to submit the changes
Click "Click here to forcibly kill entire build" link
Use screenshot for reference
I had many zombi-jobs, so I used the following script:
for(int x = 1000; x < 1813; x = x + 1) {
Jenkins .instance.getItemByFullName("JOBNAME/BRANCH")
.getBuildByNumber(x)
.finish(hudson.model.Result.ABORTED, new java.io.IOException("Aborting build"))
}
Using the Script console at https://my-jenkins/script
import hudson.model.Job
import org.jenkinsci.plugins.workflow.job.WorkflowRun
Collection<Job> jobs = Jenkins.instance.getItem('My-Folder').getAllJobs()
for (int i = 0; i < jobs.size(); i++) {
def job = jobs[i]
for (int j = 0; j < job.builds.size(); j++) {
WorkflowRun build = job.builds[j]
if (build.isBuilding()) {
println("Stopping $job ${build.number}")
build.setResult(Result.FAILURE)
}
}
}
Have had the same problem happen to me twice now, the only fix sofa has been to restart the tomcat server and restart the build.
A utility I wrote called jkillthread can be used to stop any thread in any Java process, so long as you can log in to the machine running the service under the same account.
None of these solutions worked for me. I had to reboot the machine the server was installed on. The unkillable job is now gone.
If the "X" button is not working and the job is stuck, then just delete the specific build number. It will free up the executor.
In my case, even though the job was completed, it was still stuck in the executor for hours. Deleting the build worked for me.
You can just copy the job and delete the old one. If it doesn't matter that you lost the old build logs.
Here is how I fixed this issue in version 2.100 with Blue Ocean
The only plugins I have installed are for bitbucket.
I only have a single node.
ssh into my Jenkins box
cd ~/.jenkins (where I keep jenkins)
cd job/<job_name>/branches/<problem_branch_name>/builds
rm -rf <build_number>
After this, you can optionally change the number in nextBuildNumber (I did this)
Finally, I restarted jenkins (brew services restart jenkins) This step will obviously be different depending how you manage and install Jenkins.
Enter the blue-ocean UI.
Try to stop the job from there.
I am looking for a way to build continous delivery with cloudbees,so each time a commit is made my code is compiled,unit tested and deployed to staging (running on run#cloud).
For simplity let's call it "staging-build". Then after some manual testing on staging env i would like to have an option to promote a particular (not the last) "staging-build" so the artifact the promoted build produced should be deployed to production env via "prod-build" job.
The basic idea was to configure "promote build" for "staging-build" job with building "prod-build" as promote action. Nevertheless clicking on promote-build does not trigger starting "prod-build". I also tried from the other side: removed building "prod-build" as promote action and enabling "Build when another project is promoted" within "prod-build" configuration. Still no success. After googling for a while i found
http://blog.cloudbees.com/2012/10/continuous-integration-for-mobile-apps.html. Nevertheless blog entry along with jenkins configuration screenshots do not reflect configurations on https://partnerdemo.ci.cloudbees.com
I finally found the root of problem: jobs to be run on promotion must be prefixed with folder name (obviously in case they are in folder). In other case their run is silently skipped - even promotion log has no "scheduling build for ..." entry. IMHO Jenkins web console should show some kind of warning in that case, just like it does when invalid job name is typed-in.
configuring a promotion to trigger your prod-build job is the way to go. There may be some configuration issue that isn't visible in your question. Please give me your account ID so I can double check your configuration
In order to get the fastest feedback possible, we occasionally want Jenkins jobs to run in Parallel. Jenkins has the ability to start multiple downstream jobs (or 'fork' the pipeline) when a job finishes. However, Jenkins doesn't seem to have any way of making a downstream job only start of all branches of that fork succeed (or 'joining' the fork back together).
Jenkins has a "Build after other projects are built" button, but I interpret that as "start this job when any upstream job finishes" (not "start this job when all upstream jobs succeed").
Here is a visualization of what I'm talking about. Does anyone know if a plugin exists to do what I'm after?
Edit:
When I originally posted this question in 2012, Jason's answer (the Join and Promoted Build plugins) was the best, and the solution I went with.
However, dnozay's answer (The Build Flow plugin) was made popular a year or so after this question, which is a much better answer. For what it's worth, if people ask me this question today, I now recommend that instead.
Pipeline plugin
You can use the Pipeline Plugin (formerly workflow-plugin).
It comes with many examples, and you can follow this tutorial.
e.g.
// build
stage 'build'
...
// deploy
stage 'deploy'
...
// run tests in parallel
stage 'test'
parallel 'functional': {
...
}, 'performance': {
...
}
// promote artifacts
stage 'promote'
...
Build flow plugin
You can also use the Build Flow Plugin. It is simply awesome - but it is deprecated (development frozen).
Setting up the jobs
Create jobs for:
build
deploy
performance tests
functional tests
promotion
Setting up the upstream
in the upstream (here build) create a unique artifact, e.g.:
echo ${BUILD_TAG} > build.tag
archive the build.tag artifact.
record fingerprints to track file usage; if any job copies the same build.tag file and records fingerprints, you will be able to track the parent.
Configure to get promoted when promotion job is successful.
Setting up the downstream jobs
I use 2 parameters PARENT_JOB_NAME and PARENT_BUILD_NUMBER
Copy the artifacts from upstream build job using the Copy Artifact Plugin
Project name = ${PARENT_JOB_NAME}
Which build = ${PARENT_BUILD_NUMBER}
Artifacts to copy = build.tag
Record fingerprints; that's crucial.
Setting up the downstream promotion job
Do the same as the above, to establish upstream-downstream relationship.
It does not need any build step. You can perform additional post-build actions like "hey QA, it's your turn".
Create a build flow job
// start with the build
parent = build("build")
parent_job_name = parent.environment["JOB_NAME"]
parent_build_number = parent.environment["BUILD_NUMBER"]
// then deploy
build("deploy")
// then your qualifying tests
parallel (
{ build("functional tests",
PARENT_BUILD_NUMBER: parent_build_number,
PARENT_JOB_NAME: parent_job_name) },
{ build("performance tests",
PARENT_BUILD_NUMBER: parent_build_number,
PARENT_JOB_NAME: parent_job_name) }
)
// if nothing failed till now...
build("promotion",
PARENT_BUILD_NUMBER: parent_build_number,
PARENT_JOB_NAME: parent_job_name)
// knock yourself out...
build("more expensive QA tests",
PARENT_BUILD_NUMBER: parent_build_number,
PARENT_JOB_NAME: parent_job_name)
good luck.
There are two solutions that I have used for this scenario in the past:
Use the Join Plugin on your "deploy" job and specify "promote" as the targeted job. You would have to specify "Functional Tests" and "Performance Tests" as the joined jobs and start them via in some fashion, post build. The Parameterized Trigger Plugin is good for this.
Use the Promoted Builds Plugin on your "deploy" job, specify a promotion that works when downstream jobs are completed and specify Functional and Performance test jobs. As part of the promotion action, trigger the "promote" job. You still have to start the two test jobs from "deploy"
There is a CRITICAL aspect to both of these solutions: fingerprints must be correctly used. Here is what I found:
The "build" job must ORIGINATE a new fingerprinted file. In other words, it has to fingerprint some file that Jenkins thinks was originated by the initial job. Double check the "See Fingerprints" link of the job to verify this.
All downstream linked jobs (in this case, "deploy", "Functional Tests" and "Performance tests") need to obtain and fingerprint this same file. The Copy Artifacts plugin is great for this sort of thing.
Keep in mind that some plugins allow you change the order of fingerprinting and downstream job starting; in this case, the fingerprinting MUST occur before a downstream job fingerprints the same file to ensure the ORIGIN of the fingerprint is properly set.
The Multijob plugin works beautifully for that scenario. It also comes in handy if you want a single "parent" job to kick off multiple "child" jobs but still be able to execute each of the children manually, by themselves. This works by creating "phases", to which you add 1 to n jobs. The build only continues when the entire phase is done, so if a phase as multiple jobs they all must complete before the rest are executed. Naturally, it is configurable whether the build continues if there is a failure within the phase.
Jenkins recently announced first class support for workflow.
I believe the Workflow Plugin is now called the Pipeline Plugin and is the (current) preferred solution to the original question, inspired by the Build Flow Plugin. There is also a Getting Started Tutorial in GitHub.
Answers by jason & dnozay are good enough. But in case someone is looking for easy way just use JobFanIn plugin.
This diamond dependency build pipeline could be configured with
the DepBuilder plugin. DepBuilder is using its own domain
specific language, that would in this case look like:
_BUILD {
// define the maximum duration of the build (4 hours)
maxDuration: 04:00
}
// define the build order of the existing Jenkins jobs
Build -> Deploy
Deploy -> "Functional Tests" -> Promote
Deploy -> "Performance Tests" -> Promote
After building the project, the build visualization will be shown on the project dashboard page:
If any of the upstream jobs didn't succeed, the build will be automatically aborted. Abort behavior could be tweaked on a per job basis, for more info see the DepBuilder documentation.