My use case:
Job A is set to run Monday through Friday at 18:00.
Job B is dependent upon Job A succeeding but should only run Monday through Friday at 06:00. (Monday morning's run would depend upon Friday evening's run). I prefer set times rather than delays between jobs.
On any given morning, if I see that Job A failed (thus Job B never ran), I would like to be able to run (fix) Job A then immediately trigger Job B.
What I have found so far only offers part of this use case. I have tinkered with Pipeline and recently upgraded my Jenkins instance to 2.89.3, so I have access to the most recent features and plugins. Filesystem triggering seems doable.
Any suggestions are appreciated.
You can use the options available in "Build Triggers".
Ex:
Build Trigger
Hope this work for you!
This is a tricky Use Case as generally you want a job to immediately follow on from another one rather than waiting for potentially three days.
Further complicated by wanting it to run straight away when you want it to.
I do not believe there is a "I have finished so kick this job at this time" downstream trigger So for the first part the only things I can think of are:
Job A kicks Job B as soon as it is finished and job B sits there with a time checker in it and starts its task when the time matches.
or Job A artefacts a file with its exit status and job B has a cron trigger for 6am mon-fri and picks up this artefact and then runs or doesn't dependent on the file contents
For the second part you could get the build Cause (see how to get $CAUSE in workflow for pipeline implementation and vote on https://issues.jenkins-ci.org/browse/JENKINS-41272 to get the feature when using sandbox).
And then get your pipeline to behave differently depending on trigger
i.e. if you went for the second option above then In job B you could do if triggered by Cron then read the artefact and do as needed. If triggered by Upstream then just run regardless.
Related
I am using Jenkins integration server for my CI/CD.
I am working with freestyle projects.
I want to get build duration once finished (in seconds) using RESTFUL API (JSON).
This is what i tried:
"duration=$(curl -g -u login:token--silent "$BUILD_URL/api/json?pretty=true&tree=duration" | jq -r '.duration')"
Duration is always equel to 0 even though i did this shell script in a post buil task.
There are a few reasons why this may not work for you, but the most probable reason is that the build hasn't finished when you make the API call.
I tried it on our instance and for finished jobs it works fine and for running jobs it always returns 0. If your post build task is executed as part of the job, then the job has probably not finished executing yet, which is why you are always getting 0.
The Api call for the build will not contain the duration attribute as long as the build is running, and therefore you cannot use that mechanism during the build duration.
However you have a nice alternative for achieving what you want using Freestyle jobs.
The solution, which still uses the Api method, is to create a separate generic job for updating your data base with the results, this jobs will receive as parameters the project name and the build number, run the curl command for receiving the duration, update your database and run any other logic you need.
This job can now be called from any freestyle job using the Parameterized Trigger plugin post task with the relevant build environment parameters.
This has the additional benefit that the duration update mechanism is controlled in a single job and if updates are needed they can be made in a single location avoiding the need to update all separate jobs.
Assuming your job is called Update-Duration and it receives two parameters Project and Build the post trigger can look like the following:
And thats it, just add this tigger to any job that needs it, and in the future you can update the logic without changing the calling jobs.
Small thing, in order to avoid a race condition that can be caused if the caller job has not yet finished the execution you can increase the quite period of your data base updater job to allow enough time for the caller jobs to finish so the duration will be populated.
I have been looking about this thing. Basically let´s say I have pipeline x and pipeline y, and pipeline x is trigerred whenever a commit is pushed, but I want this pipeline x to check if pipeline y is running and if so wait untill it finishes... is there any way to do this? I though of having global variables for Jenkins as flags but that would just stop from running no wait until the other job has finished
It seems like you want to have a set of mutually exclusive jobs.
You're in luck, since there's a couple of different plugins out there that can do this, one of which is: https://plugins.jenkins.io/build-blocker-plugin/
As long as your jobs use a naming convention that don't accidentally clash when waiting for one another, you should be safe.
I think this is related to the "id" field maybe, previously we weren't setting that and had issues where the multibranch job was reindexed all branches as new. That's fixed now but there is another issue.
Every time the job dsl runs it causes a branch scan job to kick off for all of our multibranchPipelineJobs.
Why does this happen ? Is there a way to prevent this ? For a few jobs it's not a big deal but we have almost 200 multibranchPipelineJobs. So this huge branch scan queue builds up every time the seed job is run. Also, according to Cloudbees there is no way to increase the number of scan jobs Jenkins processes at a time. So it always takes forever to burn down.
This is stupid, am I doing something wrong ? This happens even if there are no changes but frankly I don't think it should happen even if there are. I notice if I modify the config of a Jenkins job and save it, it usually just kicks off a branch scan job so maybe this is Jenkins behavior?
It seems like the ugliest way to handle this, but can you have the job dsl kill scan jobs in the queue for jobs it just configured and not affect other scan jobs that aren't related to the seed job run?
I am building a project in Jenkins and want to launch tests right after it, wait
until the tests are finished and than run another job to analyze the results. The testing system is a close system (I can't modify it) so in order to check if the tests are finish I need to query the system every X seconds. One way to so that is to create a job that will query the system but it will take a slot (I can create 1000 slots but it looks like a hack). is there another way to make the job "sleep" while it is waiting for the next X seconds so it will not take a slot while waiting for another process to finish ?
You can trigger one Jenkins job from another. No need to make jobs sleep or anything complicated like that. Look at upstream and downstream triggers using the parameterized build plugin.
https://plugins.jenkins.io/parameterized-trigger
I've got two Jenkins jobs, a continuous integration job that runs whenever a new change is submitted, and a build/deploy job that runs everyday at noon. I do not want the builds to run simultaneously, so I am using the Throttle Concurrent Builds plugin to force only these two jobs to queue up if either of them is already running. Any of my other jobs are allowed to run at the same time as these two jobs.
I would like the build/deploy job to always run at noon, but sometimes a developer submits a change just before noon causing the build/deploy job to wait until the CI job finishes.
Is there a way to block only the CI job during a defined time frame, like 11:30am until 1pm, so that the build/deploy job will not be blocked at noon?
IMHO the are few possibilities:
a first pre-step which check the date and exit with error if the date do NOT match the requirements
two jobs which disable and enable the job programmatically calling the REST
eg job 1
curl -X POST http://usr:pwd#host/job/joobname/disable
and job 2
curl -X POST http://usr:pwd#host/job/joobname/enable
at given time.
You can try to add slave node which is offline from 11:30am until 1pm and restrict change-caused build to this.
Second possibility is to enable SCM poll schedule to check for changes during allowed time-frame.