I have a Jenkins job that should not start building until another job has been built successfully at least once. They are not related per se, so I don't want to use triggers. Is there a way to do this?
Some background: I'm using SCM polling to trigger the second job. I've looked at the Files Found Trigger plugin, but that would keep on triggering the second job after the first on has been built. I've also found the Run Condition Plugin, but that seems to work only on build steps, not on the entire build.
Update - The second job copies artifacts from the first job. As long as the first job has never completed successfully, the Copy Artifact step fails. I am trying to prevent that failure, by not even attempting to build the second job until the first job has completed once.
One solution is to use the Build Flow plugin.
You can create a new flow job and use this DSL:
I've used 10 in the retry section but you can use any numbers.
This flow job can be triggered by monitoring the same SCM URL of your second job.
Update, here is a second solution.
You can use the HTTP Request plugin.
If you want to test that your first job has been built successfully at least once, you can test this URL:
http://your.jenkins.instance/job/your.job/lastSuccessfulBuild/
One example:
As my build has never been successful, the lastSuccessfulBuild URL doesn't exist. The HTTP Request changes my build status to failure.
Does it help?
The Block queued job plugin can be used for this: https://wiki.jenkins-ci.org/display/JENKINS/Block+queued+job+plugin
Related
I am trying to build a pipeline that gets triggered by other pipeline and should not be able to be queued by itself. I am unable to find a way to do the same. Any help would be greatly appreciated.
Updated:
Structure i am looking for is PipelineA triggers PipelineB and waits for PipelineB's completion. If i add a trigger saying start when completed it wont trigger PipelineB since A is technically not complete.
Thanks
Assuming you are using Azure DevOps, you can add a pipeline trigger to run your pipeline upon the successful completion of the triggering pipeline.
To prevent triggering two runs of a pipeline, you must remove its own CI trigger or pipeline trigger.
We do not have this build-in feature at present. You need to customize yourself.
Triggering a pipeline can be done via the API and trough PowerShell. You can write your own script file and use the PowerShell tasks.
Then you could use Rest API to query to build result for you have triggered above.
Finally use a task Conditions.
Inside the Control Options of each task, and in the Additional options
for a job in a release pipeline, you can specify the conditions under
which the task or job will run.
Unless the query result of you trigger build PipelineB is completed/succeed. Then you could continue to run left tasks in Pipeline A
I'm a bit new to Jenkins and I'm having an display issue with Build Pipeline plugin. I'm executing some jobs in parallel using JobFanIn Plugin, i.e. the next job in the pipeline will only be executed when all the previous jobs are concluded. However, the Build Plugin believes that all jobs will trigger a new instance of the last job. The execution goes right, but the display isn't.
Bellow is possible to observe what is happening in practice. The GENERATE TEST REPORT job will only be triggered when all TEST jobs are finished and this occurs ok. But since the Build Pipeline plugin expects 3 instances of this job to happen, only one happens and the others appeat as pending forever.Any ideas?
First image displaying what is happening
Second image displaying what is supposed to happen
I know about the build blocker plugin but doesn't seem to work. Running Jenkins 1.609.
Job A triggers Job B.
I configured Job A to block if job B is running.
If you trigger A and while A is running you trigger A again, once the first A finishes, it triggers B. Then you get both A and B running which shouldn't happen. I guess that when the waiting A checks if B is running, it might be the case that Jenkins is in a middle state where it finished A but not yet really triggered B and therefore we get both of the jobs running.
How can I get this situation to work?
No need to use plugin. I have been using below solutions for a year.
Job Config --> Advanced Project Options --> Block build when upstream project is building
I would say it depends if you have a chain of jobs which need to be blocked.
I can suggest:
Build Blocker Plugin
Here you can set a regular expression to block certain jobs.
With:
.*PART_OF_YOUR_JOB_NAME*
You can block every job which matches this string
I am using 4 Jenkin jobs for Continuous Build and Deployment.The jobs are created for label creation, build using the label, deploy to server1 and deploy to server2 and so on..
The Create_label build will run the MYSQL query in database and get the label. Create_label job on success will invoke the Build-job with the label and upon successful completion of Build-Job, it will invoke Deploy-server1 job and so on..
If the build fails in Build-Job and after that If I start the 1st Create-Label job then it runs the job and creates the NEW label. I mean running the create-label every time will get you incremental label. I can only get the label from 1st job and then pass to 2nd job. Can anyone suggest how to resume from the failed job with out running the first job and start with second job using the old label created(from the last build in 1st job). any work around to accomplish this type of situation in jenkins.
1.Create-Label
2.Build-Job
3.Deploy-server1
4.Deploy-server2
So it seems, you have 2 issue at the moment:
Issue 1 --> If any job fails, the next time it should skip the successful jobs and restart only from the failed job.
Probable Solution --> You could use Build Pipeline plugin, https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin , and if the job fails at say second job, then all you have to do is restart the second job from the pipeline and it would continue from there.
Issue 2 --> For job 2, you not only want to restart it but have to take the input, Label Number, from the previous successful job 1, without restarting job 1
Unfortunately, I don't have a clean automated solution for this. The only thing I can think of requires manual intervention, i.e. since this job is parameterized, change the default value of the parameter to the Label Number from the last successful job 1 before restarting it from plugin(The above plugin doesn't ask for parameters while running the job)
or let Job1 login the label number in some centralized location and let job B take the parameter from there instead of taking it from jobA.
Thanks,
Manish Joshi
I am using MultiJob plugin and you can always just click "Resume build" in the parent job to continue from a failed job.
And in this case the parameters for its execution will be all the same as on those previous run which failed.
My Jenkins server is set up with two jobs A and B say.
Job A is triggered from changes in subversion, runs unit tests and if successful, creates a WAR and deploys it to another environment.
If Job A succeeds, then Job B triggers. This job runs tests against the deployed WAR.
The problem is that the deployment process takes a while and the WAR is not ready in time for when Job B starts and tries to use it.
I'm looking for ideas on how to delay Job B until the WAR is up and running.
Is there a way, once Job B is triggered to wait for x seconds? I really don't want to put it into the tests in Job B if I can avoid it.
Thanks
There is definitely a way for a job to wait - just put sleep into the first shell build step. Alternatively, you can set 'Quiet period' - it's in Advanced Project Options when you create a build.
That, however, is a band-aid solution to be employed only if other approaches fail. You may try the following: if there is a way to make the deployment process (that job A triggers) right before it finishes to touch a file that Jenkins has access to, then you can use FSTrigger Plugin. See use case 3 there.
The most reliable way to make this work would be to make job A not complete until the deployment is successful, e.g. by testing for a valid response from the URL of the deployed web app. This blog post describes one way to do that.