Ever since we upgraded to 1.614 we have a problem with a certain hierarchy of tasks.
Two tasks are being stuck in "pending" every once in a while.
One task is descendant of the other and we indicate:"Block build when downstream project is building"
Notice that it does not say "Downstream project <> ..."
I have tried to upgrade again and we are currently on version 1.616
To solve this I cancel one of the tasks manually and the other one starts to run, but they are stuck until I notice that.
Can I prevent it from happening or at least auto cancel somehow when it happens?
Re "Can I [...] auto cancel somehow when it happens?"
See Build-timeout Plugin:
This plugin allows you to automatically abort a build if it's taking too long. Once the timeout is reached, Jenkins behaves as if an invisible hand has clicked the "abort build" button.
Seems like there is an issue in Jenkins that should was solved in 1.618
Problem did not reoccur after upgrading
Related
For internal reasons, one of my jobs is able to run concurrently, but new builds abort themselves if another build is already running (disabling concurrency doesn't help, since I don't want new jobs to be scheduled for execution once the current build is done).
However, this behaviour is detrimental to the job status preview (the colored ball next to the job name when inside the job's parent folder). It often shows the status as "aborted", which is undesirable - I want to view the latest running build as the source of the job status.
I tried deleting aborted builds from within their own execution, but that's unfortunately neither trivial nor stable, and thus not suitable for this situation. I could probably get a workaround running that deletes them from a separate job, but that's not ideal either.
Anyway, I'm now hoping that I can just tell Jenkins to ignore "aborted" builds in the calculation of the job preview. Unfortunately, I wasn't able to find a setting or plugin that allows me to do this.
Is this possible at all? Or do I need to find another way?
Would something like this help?
https://plugins.jenkins.io/build-blocker-plugin/
I haven't used it myself but it supports blocking builds completely if a build is already running.
The scenarios is like:
Initially we scheduled 3 jobs in jenkins named like core, api-simulator and ui-sumilator. core is main build and triggered build once in week. api-simulator and ui-simulator are dependent. Once core is executed, it triggered other both jobs. So we can say core is parent of other two.
Somehow, someone changed the build triggered rule for core job and set it to 3 times in everyhour. So it executed so many task for core job. Meanwhile it triggered job for other two also.
To stop all those executions, I disabled all 3 jobs.
But now we are facing issue like when we manually click on build now, it starts building but eveytime it generated next task also. If we keep it running, it will generate new schedule one by one continuously.
Even I created new job for same repository and tried but facing same issue.
screenshot of execution
Can anyone have an idea how to stop that auto triggered schedule task or remove all those task?
Seems to be, that you've configured triggering your downstream jobs from main job and at the same time in your child jobs you've configured main job as upstream job.
So, re-check your configuration, and if that - you need to disable upstream job in child jobs.
Thanks #biruk1230 for your answer.
It has been resolved by just done the minor configuration change in Jenkins. I updated Branches to build value to "master". It was "*/master" previously.
You can view from Reference link
Problem :
A certain task often crashes the slave, which then should reboot (sometimes it doesn't). If the reboot fails, it may take a week until someone reboots the computer. Then the build which failed couldn't archive the artifacts.
Idea to solve it (if there is a better one please tell me) :
To have a task always launch after this one which checks if the artifacts failed to be made (I have a way to check it), and then wait forever until the slave becomes available again, to archive the artifacts.
I know it's possible to do such for every job, but I cannot find how to do it for a specific job.
The best solution is to actually fix what crashes your server.
But for now you can add another job:
In Jenkins create a "New Item".
Make this a freestyle project.
In the "Build Trigger" section, select "Build after other projects are built".
Here you select the other job that causes the slave to crash.
Afterwards add you monitoring-and-restart-script as a build step.
The projects concerned in my linked solution are the initialise database, import database and export database.
If the initialisation succeeds then 'export' should be called. If it fails then 'import' should be called.
dbinit
/ \
export import
Logically this is simple enough; however, due to my lack of Jenkins experience, it's causing considerable grief.
I've looked at the following plugins:
Conditional BuildStep - this basically adds an 'if' statement to the build. I investigated this with the idea that the export/import projects can be collaborated into one project, using the condition to decide which course of action to take. This could work if I was able to check the condition of the upstream build (success or failure)
Post Build Task - executes a shell script based on the log output. This would go in the dbinit project. The problem with this is that I would like import/export jobs to be separated from dbinit. This would work IF I could call another job from the shell
Parameterized Trigger - This could be perfect. This would basically solve the problem by deciding which job to run based on the status of that build. However, at the time of writing, this plugin does not perform correctly with Jenkins version 1.481 or above. This problem was raised a month ago (see error link, dated the 12th Sep 2012) and has still not been fixed, therefore I am still looking for another solution.
Can anyone tell me how to overcome the identified problems with any of these plugins?
Or is there another route that I've overlooked?
Many Thanks,
Rory
In case jenkins 1.481 or later doesn't give you anything you need, and Parametrized Trigger works, then simply use 1.480, and wait 'till problem gets fixed (it is sure to get fixed, that's so popular plugin).
Would the Build Result Trigger help you?
With the BuildResultPlugin, you configure jobB to monitor jobA build result. A build is scheduled if there is a new build result matches your criteria (unstable, failure, ...)
My fairly-large project uses gated builds, with a heavily-customized process template (XAML). For reasons beyond the scope of this question, our process has a single SharedResourceScope, so multiple builds don't run in parallel (I know you're supposed to do that with an Agent scope, but we switch agents in the middle, so wrapped everything with the SharedResourceScope).
Now, if there are several check-ins in queue, all of them go into "In Progress" state, and all but one wait on the SharedResourceScope. This means that:
People can't know which build is actually running
Even if I set a new queued check-in to be high-priority, it can't overtake all those who are in progress and waiting on SharedResourceScope, so the whole priority setting has little meaning.
I've experimented using DefaultProcessTemplate.XAML, and I see that usually only one build is In Progress (though Occasionally I see 2 builds).
Questions:
When exactly does a build start, and therefore goes into "In progress" mode? What prevents all builds from starting immediately, and blocking on AgentScope / SharedResourceScope?
Is there something I can author in my XAML to prevent all builds to go in progress?
A build starts when the build controller has capacity to start a new build. Since builds can use 0 to n agents, the controller doesn't wait to get an agent before the build starts. The controller determines its capacity based on the "Maximum number of concurrent builds" setting on the controller properties (in code: MaxConcurrentBuilds).
Default setting: "Default to number of agents".
No way in XAML to control this behavior.
Also, there's a bug in TFS2010 regarding this, hotfix: KB2567437
Using TFS Build Extensions, you get a number of activities with which you can administer agent control through the process: QueryBuildAgentStatus, IsBuildRunning, SetBuildAgentStatus to name a few that could be useful to you. They're fairly undocumented as of now, so you'll have to experiment to get them running. But there is a help file included in the package that is useful.
As for the "In Progress" mode, I've noticed that this is the status even if a build is waiting for a free agent; check the log of such a build and you'll see. This is quite confusing, and I hope that MS will add a "Queued (but not started)" mode.