I currently have hundreds of builds in the build queue. It will take several days for them all to be built.
I want to bring a specific build to the front of the queue to have it build next.
Currently, the only way I have of doing that is to kill all of the other jobs in the build queue and then re-trigger them.
It seems that surely there must be a better way.
Is there?
Looks like there is no such built-in functionality.
Please, have a look at the jira issue: Ability to move job to top of queue
Although, there is a plugin which seems like a possible solution for you: Accelerated Build Now Plugin
The Jenkins Accelerated Build Now Plugin allows Jenkins users to launch a project's build right away, even if the queue is long (moving it to the top of the queue) and even if no executor is available (killing and rescheduling builds not launched by "humans")
Maybe this plugin will help you : https://wiki.jenkins-ci.org/display/JENKINS/Accelerated+Build+Now+Plugin
https://plugins.jenkins.io/simple-queue/ is a plugin that allows changing a build queue order from UI manually. And it seems to be a viable solution in 2022.
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.
Just looking for input on this one, but is there any benefit for disabling or deleting jobs?
Does disabling a job force the slave/node to remove any workspaces for that job or does disabling a job change how much the master has to work through?
TIA for any feedback.
Disabling a job is useful when it is a scheduled job, or one triggered by a hook
Few cases it could be of interest to disable a job:
You are aware of a third party service causing issues and you do not want your job to partially execute and fail, you could disable it the time the issue gets resolved by the team in charge of the 3rd party service.
Or someone in your team wants to make a demo on a server that gets updated by jenkins and would like the server not to be redeployed during the demo
You are working on a job that is not finally done, you have an urgency and want to disable the job until you can get back to working on it
Finally, in my opinion, if you only have pipeline jobs generated by a Jenkinsfile for each projects. You won't need to disable a job ever
Actually, there is no real benefit for disabling or deleting jobs. Up until now, I only see one benefit when you put Jenkins jobs in a pipeline, so you can test each upstream job without trigger downstream job mistakenly.
Disabling a job doesn't remove any workspaces on the slave/node and doesn't influence how much the master has to work through.
I have a plugin in Jenkins for Checkmarx which scans the source code for static code analysis. Is there to make that plugin be compulsory for every job in jenkins?
For that matter any plugin.
The answer, that you probably don't want to hear, is: No.
The only way you can enforce something to happen at all times, is by writing your own plugin for your own "Project type" (instead of Maven or Free-style), and then enforce that everyone uses your project type.
Found a implicit way to do it.
Using jenkins rest api(batch,python,ruby) - run through all job
config.xml.
Download the jobConfig.xml
Update the xml with the plugin(checkmarx in this case) config
Upload(POST) it back to jenkins server.
Run this on a schedule and it shall force everyone to use it.
As I said its an implicit way of doing it.
Checkmarx plugin provides a build step, so it will run every time the job runs. No need to force, if I understand the question correctly. Just make sure the "Skip scan if triggered by SCM Changes" flag is unchecked, which is the default. See more info about the plugin here: https://checkmarx.atlassian.net/wiki/display/KC/Configuring+a+Scan+Action
Downloading the config.xml for the job and posting it back is a bad idea for several reasons. First checkmarx does not require the code to be compiled so you are wasting precious cycles on a build slave. Second Jenkins jobs can do more than compile and they could deploy to production accidentally. Just don't do it. The best way to do what you want to do is to download the config.xml file and then extract the repository url. You can use the Checkmarx rest api to perform a scan. You can probably name the program in checkmarx in some way to relate it back to the jenkins job.
I have a requirement to do a dependent build using Jenkins Following is the requirement:
Project 1 has a branch which is used among two release lines. For example project1 development branch ikt/master is share in two release line rel1.2_4GB and rel_1.2_2JB.
When ever a change is submitted in ikt/master of project1 it should trigger build of both the release line rel1.2_4GB and rel_1.2_2JB simultaneously.
Build results should wait for other build to pass means both builds should be green.
Please suggest me steps using both plugin as well as without plugin (if possible).
Kind Regards,
I think your best option is to use the Parameterized Trigger Plugin to do this.
It's very simple and easy to use and you can trigger several child jobs and wait for their results. Based on their results, you can choose to fail or pass the build.
I suggest you read some more about it and do some experimenting. It works very well for me.
I hope this helps.
NOTE - I suggest not wasting time looking for a non plugin solution. If you have a good tool, use it. Don't loose time trying to be smarter...
I'd like to be able to stop build for some build definitions programmatically.
First I thought about creating some event handler (soap service or TFS plugin) to solve this issue. But unfortunatelly it seems like there isn't appropriate event in TFS (that would be raised when build is just started).
Is there the way to solve this issue?
Thank you!
Elena
Upd:
The problem has been solved by call of cutom build task in the very first target in TFSBuild.proj
Most build monitors seem to periodically poll TFS to see if there's any new builds, this obviously won't work for you as there will be too much of a delay to cancel the build.
I suggest you modify the build template to do a web request right at the start. Or just putting the logic to cancel the build in the actual template.
May i ask why you need to cancel builds anyway? there may be a better alternative.