I have one Jenkins job that triggers another job via "Trigger/call builds on other projects."
The triggered downstream job sometimes fails due to environmental reasons. I'd like to be able to restart the triggered job multiple times until it passes.
More specifically, I have a job which does the following:
Triggers a downstream job to configure my test environment. This process is sensitive to environmental issues and may fail. I'd like this to restart multiple times over a period of about an hour or two until it succeeds.
Trigger another job to run tests in the configured environment. This should not restart multiple times because any failure here should be inspected.
I've tried using Naginator for step 1 above (the configuration step). The triggered job does indeed re-run until it passes. Naginator looks so promising, but I'm disappointed to find that when the first execution of the job fails, the upstream job fails immediately despite a subsequent rebuild of the triggered job passing. I need the upstream job to block until the downstream set of jobs passes (or fails to pass) via Naginator.
Can someone help me know what my options are to accomplish this? Can I configure things differently for the upstream job so it relates to the Naginator-managed job better? I'm not wed to Naginator and am open to other plugins or options.
In case its helpful, my organization is currently using Jenkins 1.609.3 which is a few years old. I'd consider upgrading if that leads to a solution.
Related
We are moving over our build system from Hudson to Jenkins and also to declarative pipelines in SCM. Alas, it looks like there are some hiccups. In Hudson, when a job was scheduled and waiting in the queue, no new jobs were scheduled for that project, which makes all the sense. In Jenkins, however, I observe there are e.g. 5 instances of a job started at the same time, triggered by various upstream or SCM change events. They have all even kind of started, one of them is actually running on the build node and the rest are waiting in "Waiting for next available executor on (build node)". When the build node becomes available, they all dutifully start running in turn and all dutifully run through, most of them without no purpose at all as there are no more changes, and this all takes a huge amount of time.
The declarative pipeline script in SCM starts with the node declaration:
pipeline {
agent {
label 'BuildWin6'
}
...
I guess the actual problem is that Jenkins starts to run these jobs even though the specified build node is busy. Maybe it thinks I might have changed the Jenkinsfile in the SCM and specified another build node to run the thing on? Anyway, how to avoid this? This is probably something obvious as googling does not reveal any similar complaints.
For the record, answering myself. It looks like the best solution is to define another trigger job which is triggered itself by SCM changes. It should do nothing else, only checks out the needed svn repos (with depthOption: 'empty' for space and speed). The job needs to be bound to run on the same agent than the main job.
The main job is triggered only by the first job, not by SCM changes. Now if the main job is building for an hour, and there are 10 svn commits during that time, Jenkins will schedule 10 trigger job builds to run. They are all waiting in the queue as the agent is busy. When the agent becomes available, they all run quickly through and trigger the main job. The main job is triggered only once, for that one must ensure its grace/quiet period is larger than the trigger job run time.
In my task I need to trigger a same job if its current build failed.
I don't want the trigger if the build got succeeded.
Is there any plugins or any other method available to do this task?
You can use Downstream Ext Plugin for this:
my_project will be triggered only if this build fails.
Note: if you want to trigger the same job, you should realize that this is a chance to have an infinitive loop. If the build always fails, it will be triggered over and over again...
The best solution is to use Naginator Plugin.
If the build fails, it will be rescheduled to run again after the time you specified. You can choose how many times to retry running the job. For each consecutive unsuccessful build, you can choose to extend the waiting period.
Jenkins Naginator Plugin
Jenkins Naginator Plugin can be used to automatically reschedule a build after a failure.
This becomes very useful in scenarios where the build fail due to unavoidable reasons like a database connectivity is lost, the file system is not accessible etc.
Configurations
Rescheduling configuration is available as a post-build-action. There are a number of configurations for you to pick correctly based on your expected (unavoidable) build failure reason.
Read further on the configurations here with a screenshot.
So I have a Jenkins Job which kicks off other jobs to run test scripts in a particular environment after code has been pushed to that environment (Example: Code is pushed to QA, Test Project is built, and then all QA tests run using "10 separate" test jobs).
This works great for the most part, however, there are times when I get "too many tests running" because people will perform lots of builds to a particular environment and that means I have multiple versions of the same tests running.
I would like to make it such that when a job runs and finishes, if its down stream jobs are currently running, they are stopped and then started again (I want the tests to run on the most recent build instead of having 2 test jobs being run on 2 different builds).
Does anyone know of a good way to do this? Or is there a plugin someone can recommend?
What I can recommend is that you add a batch file containing a HTTP request to cancel the last build of the job in question and then trigger the job in the next step. I think the URL below should help.
So in PostBuild step of JOB-A add a condition(single-and) step to check if the JOB-A successeded then
Execute a batch command to CANCEL JOB-B
AND
Kick off JOB-B again
Thsi should do the trick. (replace the HUDSON_URL)
HUDSON_URL/job/JOBNAME/lastBuild/stop
obviously if you may need to consider authentications if Jenkins requires a login.
Also i would say maybe in JOB-B you might want to set to block if upsteam project is building so it waits for the upstream job if its not running yet.
another reference here:
Hope this helped.
In Jenkins, If one build is currently running and next one is in pending state then what should i do so that running one should get aborted and next pending one should start running and so on.
I have to do it for few projects and each project has few jobs in it, I tried to save build_number as env variable in one text file (build_number.txt) and take that number to abort previous triggered build but making build_number.txt file for each job is not looking efficient and then I have to create many build_number files for each job for every project.
Can anyone please suggest me some better approach
Thanks
Based on the comments, if sending too many emails is the actual problem, you can use Poll SCM to poll once in 15 minutes or so, or even specify quiet time for a job. This will ensure that build is taken once in 15 minutes. Users should locally test before they commit. But if Jenkins itself is used for verifying the commits I don't see anything wrong in sending an email if build fails. After all, they are supposed to know that, no matter even if they fixed it in a later update intentionally or unintentionally.
But if you still want to abort a running job if there are updates, you can try the following. Lets call the job to be aborted as JOB A
Create another job that listens on updates same as that of the job that needs to be aborted
Add build step to execute groovy script
In the groovy script use Jenkins APIs to check if JOB A is running. If yes, again use APIs to abort the job.
Jenkins APIs are available here
I have a Jenkins job which compiles and publishes our Java project to a JBoss server. Obviously, the server takes time to start and deploy the new code. I have a second Jenkins job that runs Selenium tests against the running JBoss instance.
I would like to make the second (Selenium) job be performed automatically as a post-build action from the first job (I have already done this), but I want it to be delayed by, say, 2 minutes. The amount of delay time isn't important, but I can't find anywhere that describes how to delay the start of a post-build job. How would I accomplish this?
In the advanced project options of a project configuration, you can set a "quiet period" that does exactly that. Jenkins will wait the specified amount of time after a build has been triggered before actually starting the build.
Alternatively, you could have the JBoss server trigger the build (e.g. by calling a URL) once it's up and running. The advantage of that is what it would take care of cases where the JBoss server doesn't start for some reason.
You might also want to have a look at the Parameterized Trigger Plugin which allows you to run builds of other projects as build steps. This way you could run the Selenium tests as part of the original job and fail if those tests fail.