I have a number of different projects, with Jenkins CI jobs configured for each of them to run tests. When I create a new release, I have a second job that coordinates between a number of different jobs that go over each of the modules in the projects and updates the versions and the dependencies in the pom.xml's. I would like to make the "update" job conditional on the status of all the CI jobs - meaning that if one of the CI jobs is not green, then the update job will not run at all.
I had a look at the Run Condition Plugin as well as the Conditional BuildStep Plugin, however it does not seem possible do configure them to be dependent on the status of another Jenkins job.
you could hit the other jobs via the API at [JOB_URL]/lastCompletedBuild/api/json and verify the result for each.
to mess around with this:
curl `[JOB_URL]/lastCompletedBuild/api/json` | jq '.result'
you probably want result to say SUCCESS.
this is not fancy, but you don't want fancy in CI; you want something that is not likely to break when you upgrade jenkins. :)
Have a [https://wiki.jenkins.io/display/JENKINS/Multijob+Plugin] ["Multijob Plugin"] ,
In your case, you can add a job in first step and configure in that step, at which result condition of first step, you want to run second step.
Again, in second step, you can configure one/many jobs and can also configure if you want to run them in parallel.
Related
I would like to have Teamcity build configuration that currently has 3 build steps:
Build an artifact to perform tests on & install on remote server
Kick off long running test job on remote server
Pause build awaiting external event (i.e. remote job finishing)
Retrieve results and record the report
I have had a look through the documentation and I can see how I can pause (step 3) the entire build configuration (which stops any additional builds running) ... but not just a single running build.
The Step 2 script that is running the external job has the various parameters passed to it, so that it can issue a REST call back to the teamcity server to resume the build job.
Basically I don't want to tie up a build agent waiting the entire hour the test takes to run.
I have googled and everything I can find points me at pausing the build configuration.
I am currently having to look at splitting the build configuration into two. The first will kick of the test job and finish. Then when the external test job finishes it will call teamcity to start a second job to retrieve and store the reports. But that feels disconnected to me in that I will not be able to show a single job with build/test/report.
At the moment (TeamCity v 2018.1) there is no direct way to pause the build, release the build agent, and later resume the execution.
What you described is the recommended workaround.
Also, please watch/vote for related issue: https://youtrack.jetbrains.com/issue/TW-30777
I am trying to build multiple Jenkins jobs, e.g. job1, job2 where jobs2 is downstream job1, each one needs to run on multiple platforms, e.g. Win, Mac, Unix
I need job2 on Mac to start once job1 on Mac has finished, same for others... but cannot find a simple way to do this simple thing!
I tried the Matrix configuration, parametrized trigger, extended trigger, NodeLabel, but non did the right job
This task looks simple but I could not achieve! Any help is really appreciated
Have you tried the Build Pipeline Plugin or Pipeline Plugin to help address this? You can also consider creating these pipeline dynamically depending on job dependency and then run.
Seems like a fit to me.
I have seen some duplicate questions but the answers didn't seem to help. The following is what I need: I have the upstream Job A and its downstream Job B. I use parameterized trigger plugin to kick off Job B once Job A finishes successfully.
I want the kicked off Job B to have the same build number and use the same SVN revision which Job A used to simplify things (Both jobs use separate workspaces BTW.)
Under Job A, I checked the "Trigger parameterized build on other projects" and added the subversion revision and current build parameters to the parameters for Job B when stable.
Under Job B, I checked the "This build is parameterized" and used SVN_REVISION as a string parameter with default HEAD; and BUILD_NUMBER as a run parameter of Job A. Under SCM, for SVN url, I entered: http:// svn-path-here/trunk#$SVN_REVISION
Doing this always pulls the HEAD and uses different build number. Any help is appreciated. Thanks.
A quick web search reveals:
With the parametrized build trigger, you need to use a "peg revision" in the SVN URL. E.g. .../repository/trunk#${SVN_REVISION}
Or you can use Tracking SVN plugin.
See this thread.
I'm trying to run the same job multiple times with different parameters via a parent job. However, only the first of the triggered jobs runs.
The parent job has the checkbox "Trigger parameterized build on other projects" checked, and there are two triggers created, each with a different parameter value for a parameter x on the downstream job. Job 1 has x=1, Job 2 has x=2. Only job 1 is run!?
What am I missing?
This is a bug in Hudson.
It was reported to Jenkins and fixed there, both in the core and this particular plugin several months ago.
See also the Jenkins vs Hudson discussion on StackOverflow for further reasons to upgrade to Jenkins.
I have a job upstream that executes 4 downstream jobs.
If the upstream job finish successfully the downstream jobs start their execution.
The upstream job, since it finish successfully, gets a blue ball (build result=stable), but even tough the downstream jobs fail (red ball) or are unstable (yellow ball), the upstream job maintain its blue color.
Is there anyway to get the result of the upstream job dependent on the downstream jobs?, i mean, if three downstream jobs get a stable build but one of them get an unstable build, the upstream build result should be unstable.
I found the solution. There is a plugin called Groovy Postbuild pluging that let you execute a Groovy script in the post build phase.
Addind a simple code to the downstream jobs you can modify the upstream overall status.
This is the code you need to add:
upstreamBuilds = manager.build.getUpstreamBuilds();
upstreamJob = upstreamBuilds.keySet().iterator().next();
lastUpstreamBuild = upstreamJob.getLastBuild();
if(lastUpstreamBuild.getResult().isBetterThan(manager.build.result)) {
lastUpstreamBuild.setResult(manager.build.result);
}
You can find more info in the entry of my blog here.
Another option that might work for you is to use the parametrised build plugin. It allows you to have your 4 "downstream" builds as build steps. This means that your "parent" build can fail if any of the child builds do.
We do this when we want to hide complexity for the build-pipeline plugin view.
We had a similar sort of issue and haven't found a perfect solution. A partial solution is to use the Promoted Builds Plugin. Configure it for your upstream project to include some visual indicator when the downstream job finishes. It doesn't change the overall job status, but it does notify us when the downstream job fails.
Perhaps this plugin does what you are looking for?
Jenkins Prerequisite build step Plugin
the work around for my project is to create a new job, which is the down stream of the down streams. We set a post build step "Trigger parameterized build on other projects " in all three of the original downstream jobs. The parameter that parse into the new job depends on the three jobs' status and the parameter will causes the new job react accordingly.
1. Create new job which contains one simple class and one simple test. Both parameters dependens, i.e. class fail if parameter "status" = fail, class pass but test fail if parameter "status"=unstable, etc.
2. Set Trigger parameterized build on other projects for the three original downstream jobs with relevant configurations.
3. Set notification of the new job accordingly.