I've created a number of script syntax Jenkinsfiles with this header:
properties([
pipelineTriggers([
pollSCM('H/5 * * * *')
])
])
They almost always trigger at least twice for every commit. Once within 5 minutes of the commit, and again at +5 minutes from the first build. The builds are shorter than 5 minutes long, meaning the second build triggers after the first build has completed. Jenkins log shows both triggers as being identical, as though the second build is not aware of the first build.
I don't understand how this isn't a larger issue. It makes continuous deployment extremely dangerous. Am I missing something?
First of all, H/5 * * * * -> H means run in the next 5 mins whenever is possible. So if the build was run at 1st minute of the hour, second one may run at 6th-10th min whenever possible (Considers other jobs are running or not). And you didn't mention anything about stopping the concurrent builds also. So it will run as per your configuration.
You can stop building multiple parallel by adding this to your script.
options { disableConcurrentBuilds() }
Hope this helps.
Related
I'd like to periodically trigger my Jenkins pipeline via a cron job with parameters to kick off a job.
One for nightly builds, quick tests, and the second for weekly, very extensive testing.
H 22 * * * %nightly=true;branch=trunk;
H 23 * * 5 %weekly=true;branch=trunk;
The second build never kicks off.
I tried several options, like more time in between and line spacing, without any success. So I have no idea why it fails.
I have a Jenkins job that sometimes runs for more than 1 hour, sometimes it just runs for few seconds. What I really need are those builds with a duration more than 1 hour.
So I would like to delete those builds with the duration less than 1 hour through e.g. the console.
I've tried a lot to find those builds. Unluckily I couldn't find a way to extract the duration information of the builds.
To get the duration of a build through the console :
build = Jenkins.instance.getItemByFullName('JOB_NAME').getBuildByNumber(BUILD_NUMBER)
println build.getDuration() // in milliseconds
println build.getDurationString() // in hour, minutes, seconds
I'd like this job to wait a certain amount of seconds based off of a string parameter given to the job. The field only allows me to enter numbers, so I cannot use $(PARAM). I want to know what would be a good way to do this.
P.S:
Do jobs in quiet period hang executors?
You could use a pipeline job that takes in the parameter and then triggers your job, setting the quiet period in the build step (see quietPeriod at the bottom). Like this:
node {
build job: 'foo',
quietPeriod: params.QuietPeriod as int,
wait: false
}
Where you've defined QuietPeriod as the parameter with the number of seconds to wait.
For those wondering about the
'P.S: Do jobs in quiet period hang executors?'
part of the original question:
No, executors are not occupied during this quiet period.
Jenkins job trigger cron expression format is ? ? ? ? ?.
It cannot possible set the seconds unit.
But I want schedule seconds unit, like run at everyday 15:20:10.
Because there is a job with cron(0 12 * * *) and every minute job, and these two job must not to run simultaneously.
How can I do that?
Thanks for help.
you can have several options to do that :
use lock plugin to wait until your first job run will finish and only than trigger it.
use the Quiet period option in the Job configuration , add 10 seconds so the job will sleep 10 seconds after it trigger.
Is there a real big advantage of using H in cron in Jenkins?
Like:
H 21 * * 1-5
instead of
0 21 * * 1-5
I prefer the last step in my case because I really want to run the job on 06.00 etc. The warning in Jenkins is always showing:
Spread load evenly by using ‘H 21 * * 1-5’ rather than ‘0 21 * * 1-5’
Do I have to bee worried for this?
As long as you are not scheduling many jobs for the same time, you don't have to worry. Just the more you schedule for a certain time, the less likely it is that they can be executed in parallel (depending on the number of executors). If you just don't care about, when a job is executed, then give Jenkins the chance to distribute the load.