I have a Jenkins server on K8s (using Rancher).
Job Y is configured to run after job X (image is attached).
Job X runs successfully, but at its end, job Y is not triggered.
Both jobs are on the same Jenkins master.
This problem has never happened to me before, on our Jenkins on prem servers.
I have checked everything I could think of, including creating test jobs that basically do nothing, just in order to test if the triggering is working for other jobs on this master, it does not.
Checking the logs - job x is in the log (image is also attached), job Y is missing from the log completely.
I will mention that on another master on the same cluster, triggering is working. Any ideas?
check the trigger condition for job Y.
Below is the one way you can trigger jobs in Jenkins
Chain jobs together
Chain Jenkins job together using the “Build other projects” option in the “Post Build Actions” of a job. The downside to this is that it introduces a dependency between jobs. For example, I want to be able to run the database backup job without doing a deployment every time.
Parameterized Trigger Plugin
When you have the Parameterized Trigger Plugin installed:
Create a wrapper job for your sequential jobs
For each sequential job
Select Build->Add build step->Trigger/call builds on other projects
Enter the sequential job name
Check the ‘Block until the triggered projects finish their builds’ checkbox (this only appears when you have the Parameterized Trigger Plugin installed)
Now when you run the wrapper job, all the triggered jobs will be run in order and sequentially. You of course also have the option of using the parameters functionality of the plugin too.
Throttle Concurrent Builds Plugin
The docs for the Throttle Concurrent Builds Plugin seem to be a little lacking, but it works well. With it installed, a “Throttle Concurrent Builds” section shows up in the Jenkins config section (Jenkins -> Manage Jenkins -> Configure System). There, you create a “Multi-Project Throttle Category”
Next, for each job that needs to be run sequentially, you
Check the ‘Throttle Concurrent Builds’ check box
Select the ‘Throttle this project as part of one or more categories’ radio button
Check the checkbox of the “Multi-Project Throttle Category” you created above
Save
Finally, you create a wrapper job that triggers all your to-be-run-sequentially jobs and when you run it, you should see your jobs running sequentially and in order.
Although a fairly complex option, this approach also allows you to run some jobs sequentially and others in parallel. For example, your wrapper job can run jobs A and B sequentially and jobs C and D sequentially, but trigger A and C in parallel. You can also combine this plugin with the Parameterized Trigger Plugin for maximum flexibility.
Join Plugin
Although I haven’t used the Join Plugin myself, it seems worth mentioning. Its docs state that
This plugin allows a job to be run after all the immediate downstream jobs have completed. In this way, the execution can branch out and perform many steps in parallel, and then run a final aggregation step just once after all the parallel work is finished.
That’s it. Several options for running Jenkins jobs in parallel. Choose the one that best suits your needs…
Related
i am new to Jenkins , i need to execute one job that run's another multiple jobs in parallel were it should not stop even if one job fails.
i am not sure how to achieve it. After googling i can achieve by 3 ways Multi-Job plugin , Pipeline multiple Jenkins jobs , Build after other projects , Build Flow Plugin.
can any body please provide me the correct way.
Update : i am trying to achieve this using the pipeline plugin , can any body suggest me were it was correct choice ?..Please suggest!..
We use the Parameterized Trigger Plugin to do this.
In your build configuration add a Trigger/call builds on other projects build step. Add the names of the builds you want to trigger as a comma separated list and make sure that the Block until triggered projects finish their builds box is unchecked. Your build will trigger each of the listed builds, however note that your parent build won't wait for them to finish it will just trigger them and then perform the rest of it's buildsteps so if you have buildsteps.
If you do want to wait then check the block until triggered builds finish box, but set the options for when to fail the build, build step or mark the build as unstable appropriately.
If you need to pass parameters to the jobs you can add parameters using this plugin. If your downstream jobs need different parameters for different jobs you can click the add trigger button which adds another project to build where you can specify different options.
If these other jobs are follow up jobs to the current job and you don't need to wait for them to finish you can also achieve what you want to do by using the post build action build other projects, but again this occurs after the current job and you won't be able to use the results.
can any body please provide me the correct way.
I wouldn't approach using Jenkins with a "one correct way" mentality. Often times the requirements of your build will dictate which method or plugin you use in your build configurations.
The job can start other jobs via the jenkins api.
updated Answer : i used pipeline plugin to achieve my task and tuffwer was right to if u have paramaterized trigger plugin!..
I've noticed that there seems to be a build queue limit of one in Jenkins. When I trigger a lot of builds it seems to only place a max of one build in the build queue. Is there a way to remove this limit so there can be more then one build in the build queue?
This is intended behaviour:
Normally, your jobs will depend on some input (from SCM, or from some upstream jobs)
If your slave capacity is too low to catch up with each and every build, then you'd normally want to test/build/... only the very latest "item".
This is the default behaviour. Without that, there'd be a risk that the build queue grows indefinitely.
On top of that, Jenkins does not track the properties of normal build requests -- they all look the same, and Jenkins can not (for example) separate different SCM states that existed at different triggering times.
This is however exactly the point that gives you a workaround: parameterize your jobs, and then use for example the Trigger parameterized build on other projects post-build action to trigger those. Then Jenkins will queue each build request individually -- and inside your job, you can use the parameter to find out what exactly has to be done.
Jenkins will squash queued parameterized builds that have identical parameter values (thanks to user "atline" for checking).
Jenkins to run 10 jobs sequentially and few parallely and let say 1-2 jobs are successful and job3 failed. I fixed the job3.Now I want to again trigger the job but only want to trigger it from job3.All 10 jobs have string parameter.
I can pick an choose what jobs to trigger. how can I achieve it.Please help.
The whole point of CI is to have multiple runs frequently, so that in next run you can see them all stable. Not sure why you wanted to do this. However, You can take 2 approaches.
You can use conditional Step plugin along with multiphase plugin,
wrap you build step with condition and pass whether you want to run
it or not. only if the condition is passed then the individual jobs
will be triggered.
You can use jenkins-cli and trigger the jobs
which ever you wish.
I've got a commit build project in Jenkins which schedules an acceptance build project on completion. Since commits come in faster than the acceptance build job finishes, after a short time there are now six queued acceptance build jobs. I would like the acceptance build project to work like the "Poll SCM" functionality - On completion, start the most recently queued job, skipping the rest.
I can't use the "Build after other projects are built" without more hacks since I need to pass information from the commit build job to the acceptance build job.
#l0b0,
Jenkins behavior is to coalesce builds so that the queue only contains the currently running build and one enqueued job. The depth only increases if the newly enqueued jobs takes parameters that differ from what's already on the queue.
So I'm gathering that your downstream (acceptance) job takes some sort of parameters, but you need to supply more details of how it's working.
If you're using parameterized trigger plugin then you should check out this existing SO thread
More generally speaking, you should look into your parameters. It sounds like you are passing too much information from upstream to downstream jobs, resulting in the the Jenkins queue treating them as distinct parameters when then is not necessarily the case.
Are you passing in the run number of the last successful upstream job as a parameter? If so, then yeah you've got problems. What you should do instead is use the Promoted Build Plugin on the upstream job to mark the last successful build, and then have the downstream job simply jump to the most recent promoted build.
Hope that helps.
I am trying to make this rather unique build flow and I haven't found a plugin or a way to do it with jenkins yet.
There is one job called "JOB A" which is used by itself and creates a standalone installer.
Then there is "JOB B" which creates another installer but it needs to include everything built in "JOB A" in addition to some other stuff. Now I could just copy JOB A build steps into JOB B, but I want to actually build JOB A and maybe even use those artifacts later as well.
It cannot be a build trigger cause JOB B needs to continue building after JOB A has finished and I cannot use something like flow because that creates JOB C and only sequences other jobs and I would need to go into A and B to get the artifacts.
Bonus points would be if it checked JOB A source code in git for any changes since its last build when building JOB B and decide if it needs to build it again.
I looked at many plugins and I can't seem to find one that would do this.
I hope my explanation was not confusing. Sorry if it was, I could elaborate.
If I understand correctly what you want, then what you need is:
Custom (shared) workspace
Parameterized Trigger Plugin
For both, JOB A and JOB B, setup Custom Workspace to the same folder on the server (You can even leave JOB A workspace as is, and just point JOB B custome workspace to workspace of JOB A. I am not at my work computer with Jenkins and can't provide screenshots, so I will borrow this great guide for more info on how to setup custom workspace
Then, whenever appropriate, have JOB A execute a build step Trigger/call builds on other projects, namely JOB B. You can even pass it all the same parameters that JOB A had. By default, this will not wait for JOB B to complete. It will kick off JOB B, meanwhile JOB A will finish running, and then JOB B completes whenever it is done.
If needed, you can check-mark Block until triggered projects finish their builds, and then JOB A will wait for JOB B to finish before continuing.
So, the above will:
Share workspace, and not do extra checkouts if code didn't change
Let JOB A and JOB B exist independently, with it's own artifacts, and each being able to be triggered separately.
JOB B will get everything from JOB A through shared workspace and passed parameters.