I have the following error when running a Jenkins task
Process leaked file descriptors
After reading this post Stack Overflow post
I ended up understanding the problem (I think). I have a build which triggers many tasks. It can for example trigger 4 builds. However, sometimes when one dies, the other dies. I guess it's because of the link that exist between the parent and childs builds like explained there Jenkins site
The solution however is with command lines and I don't use a command line to trigger my build.
Is there a way to have a similar solution when triggering a build with the "Trigger/call builds on other projects" action.
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.
We are using the Parameterized Builds plugin and a matrix combination parameter. So now, when we build this job, we select which of the combinations we want to build and one "child job" is created for each one that is selected.
Each of these jobs runs their build steps and post build actions. However, I have also noticed that the post build actions run for the "parent job" as well.
For example, we have the job configured to post a message to Slack upon success. Now, if I build the job with parameters and select one configuration to build, I will get two Slack notifications. One for the main job and one for the selected configuration.
Example Slack output, note one with the config selected and one without:
| My Jenkins Project » My Job » my config - #51 Success after 1 min 54 sec (Open)
| My Jenkins Project » My Job - #51 Success after 1 min 55 sec (Open)
So my question is, how can I prevent post build actions from running on the main job?
EDIT: Since creating this question I found this GitHub issue on the Slack plugin that describes exactly what I'm seeing. So it looks like this functionality should be up to the plugins and that a new version caused a regression in this particular plugin.
Perhaps the question is better suited as: Is it a plugin's responsibility to determine whether it is running in the global job or in a configuration job as part of a multi-configuration project?
Whether a message should be posted on Slack for only the child jobs or the parent job also should be part of the configuration that the plugin provides. Here's an example from your github link. The hipchat plugin gets this right:
A similar option from the Slack plugin would solve your problem, there seems to be a PR here to fix it. You can revert back to an older version (<= 2.0) to solve this meanwhile.
General Symptoms
We use Jenkins to build & test on multiple platforms. We use the Configuration Matrix plugin to help with this. Occasionally (increasingly often) Jenkins will mark the Configuration Matrix master job or subjobs as failed when the jobs seem to have succeeded (the console output reports success). We have no idea why this is happening. Any suggestions?
Some clues:
The exit code of the Jenkins job's script is not relevant. We've had test sub-jobs that simply exit 0 and they can still exhibit this bad behavior.
The failures are bunchy. They seem to come in groups.
The failures tend to effect our Windows platforms more heavily but the issue occurs on our Mac nodes as well.
The failures clump on a single node for a time but they are not exclusive to any 1 node.
We've noticed that the failures happen most often with load, particularly failed sub-jobs are started later than their successful sibling sub-jobs (often after other siblings have already completed).
We suspect that the sub-jobs are somehow considered completed by the master before they actually complete. Since they're not done the master sees them as failed. Later the sub-job really does complete (thus the console output says Success). We suspect this because we've added comments to "failed" jobs which look incomplete only to return later and see additional console logs.
It turns out that there is a bug in either the Jenkins "Set Build Name" plugin or the "Configuration Matrix" plugin. When you use them both you're subject to a few bugs. First is the symptoms I described above. Second is that the names set on builds can be wrong (race conditions mean that the wrong name can be applied).
There is a ticket open against Jenkins here. Unfortunately there isn't currently a posted work-around. We may simply stop using one of the plugins.
I've got a job that runs for a long time (for example, it builds few solutions), Is there a way to know the current solution that is beind compiled on runtine?
I mean, the Log is very long, so sometimes is confusing to know what is the current compilation that is running.
I want to know what is the current solution that is being compiled now...
Any plugin or a way to do that?
It would be easier to diagnose problems if you split the job into multiple jobs (each one building a single solution). If you have dependencies between the different builds (i.e. one part of the build cannot happen until another part has completed), you can create a build pipeline, where once one job finishes, it triggers the next job in the pipeline. You can do this using the post-build action Build other projects in the job configuration.
There is also an excellent build pipeline plugin which helps you visualize your build pipeline.
If it is the case that you must have the whole solution built in a single job, then one approach would be to use the Jenkins log parser plugin to display a cut-down version of your build log, which just highlights the key events you are interested in to diagnose such problems.
More details of this plugin can be found at:
https://wiki.jenkins-ci.org/display/JENKINS/Log+Parser+Plugin
I've got two ideas for a possible solution but they needed to be implemented:
1. Adding a prefix for each row in the Log. The prefix could be a string.
for example, if there was a new Project Compilation started then the Log finds the line
----- Rebuild All started: Project: PROJ1 , Configuration: Release x64 ------
Then it adds all the rows after it the prefix "Building PROJ1"
until the log reads the next project:
----- Rebuild All started: Project: PROJ2 , Configuration: Release x64 ------
2. Adding a the current project name that's building to the flashing Job status blue ball.
I mean, finding the current building project from the Log, then adding it next to the current job status (the flickering ball).
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, ...)