I have a jenkins declarative pipeline job which invokes a shared library. The groovy script in the library executes a couple of quick commands and then polls for the result (with Thread.sleep()) which could take up to 10 minutes. However after 5 minutes the thread is interrupted, which is by design. The discussion in the previous link mentions that such workloads should be done
in a step so it can happen on a background thread rather than holding up this thread
But it's not clear what is implied here. The shared library code is invoked from a script block inside a step.
In theory a while loop that only exits when the program receives the correct signal that jenkins sends when you click stop should work. But jenkins seems like the wrong tool to manage a long running process, I would look into systemd or other OS level init system so I could pass the responsibility of keeping the process running onto my ops team.
Related
I do have a job which requires external ressources and therefore it should not executed twice or more often. I used Block Queued Job Plugin to block the job if of a list of jobs is currently running.
This creates sometimes a build queue with some jobs blocked by the plugin ... which is correct.
But now I do need to reorder the build queue to give a specific build a chance to be executed.
There is usually just the fifo principle in place but I do need to overwrite this in specific situations manually.
simple queue plugin ... can not deal with blocked jobs
priority sorter .... sees to be outdated and not working for such a simple thing ...
Currently I write down the parameter handed over per job delete all and afterwards rebuild with the new order and with the parameters which were manually written down.
This is quit bad and I do need a working solution. Maybe I missed the right plugin.
I am using opencensus in my component, I am running a performance test with JMeter started by Jenkins, but the process never ends and I discovered that it is opencenus that is keeping it alive (because if I remove opencenus the process finishes/dies normally).
Is there anything I can do in opencenus, Jenkins or JMeter to force the job to finish? Aborting the job also does not help as per Jenkins do not collect the results then.
IIRC, there's nothing inherent in OpenCensus that would cause this.
Caveat: I've mostly used OpenCensus with Golang, Python and JavaScript but not Java.
However, if, for example, you're using the Prometheus Exporter, it's common to run this in a separate thread because the e.g. Prometheus server needs to scrape (via HTTP) a metrics endpoint that's exposed by your component.
Could it be that it is this that's keeping your component alive?
If so, there should be a mechanism to gracefully terminate the Exporter once your component is done with it.
zPages and possibly other Exporters take this background thread approach too.
When using Jenkins CLI, I can use the build command with options -v and -s to run a build, waiting for it to finish and printing its output.
Is there any way I can achieve the same result (wait for execution and get job output) with a single call to the REST API? I know this can be done by polling for build status until it finishes and then requesting its output, but I want to know if there is a straightforward option for short-running jobs.
You can do like that somehow. But even if you do also you can't able to apply the same code for other jobs. There will be waiting period for the next available executor or some race conditions like this might happen. And holding the rest API for that long period is not gonna be a good option. And nobody suggests that.
So Instead of looking for the REST API, you can have an algorithm for polling itself. instead of every second, take results from the previous builds and process it and try to predict the near possible time and then poll. Like this kind of algorithms or else you can use Jenkins build remaining time also. Hope this makes sense.
I manage a Jenkins server with a few hundred projects in the whole ecosystem. Many of the projects rely on upstream servers, that, unfortunately, are not always responsive. When I have a lag on these servers, my build queue can get to 10 or more. Is there a plugin or setting to send a warning email when the build queue exceeds a particular length?
I have been unable to find a plugin that does this, but you can query Jenkins for the information as detailed here: Jenkins command to get number of builds in queue.
If you have a Jenkins slave available you could set up a job that runs every 15 minutes and just hit each of the other Jenkins servers with the API call to get build queue counts (this is easy if you have just one master and many slaves.)
If you wanted to stay completely outside of Jenkins (not add another job to the mix) you could write a script to poll the Jenkins API for the information. You could then run that script under, say, a 15 minute (or some other relevant time step) timer using cron (or windows scheduled task). Admittedly then you have to dedicate some resources to running this job.
It looks like you could use python to get the build queue and check the length of the returned list. get_queue_info()
I haven't mucked about with the Jenkins API much myself so I'm not sure offhand exactly what the script would need, but it should be simple enough once you dig into it.
I have a job A running in Jenkins, which kicks off a process A on a VM, waits for it to finish, picks up the report generated by it and sends it as an attachment to the build notification. The problem is this process A takes too long to finish and job A keeps waiting on it. Is there any way I can start this process A, stop job A and when process A is done, trigger a new job B which would pick up the report generated by process A and sends it out with build sucess/failure status.
Any help is appreciated.
Thanks
Jenkins provides an API for kicking off jobs via simple HTTP requests. You kick off job B using curl or something like that, as the final step in process A on the VM.
The docs are on the Jenkins site. You can use your own Jenkins find the specific URLs for kicking off particular jobs; there's a link in the bottom right hand corner of the Jenkins page.
Perhaps an even better match for your use case would be a job of type "Monitor an external job". I have not used it myself, but from the documentation it sounds like a useful tool. The docs are at: https://wiki.jenkins-ci.org/display/JENKINS/Monitoring+external+jobs