I have a large multi-module maven project, which is handled by a number of jobs in jenkins.
I have noticed that not all downstream jobs are trggered when an upstream job finishes successfully. The upstream and downstream jobs are calcualated automatically by Jenkins. Sometimes a subset of the jobs are triggered, and sometimes none. This puzzles me, any good explanations out there ?
In the category better late than never:
There was a bug in the maven job code which would ignore triggers if upstream dependencies were still building :
see https://issues.jenkins-ci.org/browse/JENKINS-21903
this was fixed end september 2014, so any relatively recent version should no longer be affected by this.
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.
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.
I was looking for the answer a few days, but haven't found an easy solution.
All the projects are related to each other by upstream and downstream triggers. In all projects set the same interval poll SCM. After the launch of the first project, the second project will start, then the third and so on. And when in the middle of the chain SCM timer triggers on any project, it begins to build of this project. There is an option to block the project until the upstream projects are building. But!!! The problem is that the CMS trigger still adds a job to the queue. I need it isn't add downstream jobs to the queue and do not do anything, if upstream projects are building. In other words, I need upstream job freezing SCM triggers in all downstream projects.
I know about pipeline, but I'm looking for something simpler. Thanks.
There are five jobs in sequential order(1,2,3,4,5). Jobs 2,3,4,5 are built successfully(but they have not come out of the execution shell), since the job 1 is still compiling. If I abort job 1 then all the results of 2,3,4,5 are updated spontaneously to gerrit.
How can I change this configuration in Jenkins master?
This is a known bug in the Jenkins mailer plugin, you need to upgrade the plugin to the latest version.
Here you can find more details:
Github - [FIXED JENKINS-20867] Never wait for a prior build to
complete merely
Jenkins - Sending mail blocks on prior build
For posterity:
One of my Jenkins jobs disappeared after I upgraded some plugins.
I looked through the error log, and found that the Promoted Builds Plugin was failing while parsing the job config.
What went wrong?
It appears that the Promoted Builds Plugin release 2.9 broke in my scenario, which specified a promotion action to build a parameterized job. I removed the section of the job conf file pertaining to promoted builds, restarted Jenkins, and the job reappeared. Then I reconfigured the promotion action, and all seems fine.