Is there any way to have a build wait until its dependency builds run and fail if they fail? I cant find one outside of this 700 dollar plugin: https://marketplace.atlassian.com/apps/1210988/run-cli-actions-in-bamboo?hosting=server&tab=overview
You will want to break the build up into multiple plans. You can set one of the builds to be dependent on the other plan under the "Dependencies" tab in Plan Configuration. There are different strategies for controlling how these dependencies trigger and block under the "Advanced options" dropdown.
Atlassian has a guide on this here:
https://confluence.atlassian.com/bamboo/setting-up-plan-build-dependencies-289276887.html
Related
I have 2 different build configurations in team-city.
Each has it's own build chain.
The first just builds the product. The second also builds the product but also builds and run unit tests. We are invoking them manually depending on our needs.
Now the question is it possible to have single entry point that will do perform conditional execution via some parameter/argument.
( I click on button, provide option to have simple build or build with unit tests )
I am thinking about having "wrapper" shell-script configuration, that will execute the chain needed via REST depending on given parameter.
However this have obvious disadvantage of broken integrity (you can't really follow what is happening)
Any other solutions welcome!
Make two TeamCity builds, one for the "build the product" and one for the "Test the product". The "build the product" build should save binaries as artifacts. "Test the product" build should have the "build the product" as snapshot and artifact dependency. Don't set any triggers for either build.
Now you can use the run custom build button. "build the product" build is easy enough just press run build. For the "Test the product" build, depending on your exact needs you might want to press the dots in the UI next to the run button, switch to the dependency tab and change the setting rebuild snapshot dependency to all to force a rebuild of the "build the product" build.
I am not very familiar with the REST APIs. If it supports running custom builds you can now use a shell script to run either the "build the product" or "Test the product". The advantage with this solution is you can now tell what is going on in the TeamCity UI.
Here's the scenario: I have a TeamCity "master" build that aggregates the results of other 11 builds.
I'm using snapshot dependencies.
This works fine in normal scenario.But in case, any of the dependent sub build fails and master build is triggered again then all 11 dependent builds get triggered.I want only failed build to be triggered not all.
Is there any way to achieve this??
In TC 8, some settings will interfere with build reusing. From the docs:
Some settings in VCS roots can effectively disable builds reusing.
These settings are:
Subversion: Checkout, but ignore changes mode
CVS: Checkout by tag mode
Perforce: Checkout by label set to Client instead of Client mapping
Starteam: checkout mode option set to view label or promotion date
(source: https://confluence.jetbrains.com/display/TCD8/Snapshot+Dependencies)
Normally, if the source code for any of the 11 dependent fields has not changes ,they will be queued but will just silently go to success
In case you just need artefacts from the previous builds, you can try setting up artefacts dependencies instead of snapshot dependencies. That way you can rerun an intermediate target if it fails and still continue for the rest of the chain. By the way if you are setting artefact dependencies you also have to add "Finish run triggers" on the targets
Also, when setting snapshot dependencies, there is an option "Do not run new if there is a suitable one". Please enable it to see if it solves your problem
I have a project which is a plugin for an opensource system. In order to run a CI build for the plugin, it needs to be installed into an existing instance of the main opensource system. I have mostly got this working, however, the install procedure for the main system is long and complex, so the build takes forever. It is also awkward to set up as checking out the plugin from git always happens first, whereas it needs to happen after the main system has been put in place so that the right directories are there. The solution I have right now is to use a shell script for the install and then an Ant task for the build, ignoring built-in VCS altogether. Feels hacky, though.
Two solutions come to mind:
Have a persistent install of the main system in the build directory, which the plugin is added to at the start of the build, and removed from at the end. I didi this ith Jenkins and it worked OK, but we are now using TeamCity.
Have some sort of parent-chid relationship between two CI projects, so that the main one is built and then triggers the plugin one, which is built within it. This would allow the main one to be rebuilt whenever it needs to be and avoids the awkwardness of keeping an install of the main system clean between builds.
However, I don't know enough about TeamCity to know if this is possible. Has anyone ever done something like this before?
For your solution number 2 you can try to use the "Build Triggers" configuration, the "Finish Build Trigger" option should resolve your parent-child relationship very well.
In TC, go to your plugin's build configuration, in "Configuration Steps" section select "Build Triggers" (number 5), then select "Add New Build Trigger" and configure "Finish Build Trigger" selecting your main system's build configuration.
To use parent directory in child one, you'll need to use the "Artifact Dependency" (see "Dependencies" section in "Configuration Steps", maybe setting some snapshots between the build configurations too.
Artifact Dependencies:
artifact Dependencies provide you with a convenient means to use the
output (artifacts) of one build in another build. When an artifact
dependency is configured, the necessary artifacts are downloaded to
the agent before the build starts.
Snapshot Dependencies: by setting a dependency of a build (e.g. build B) on other build's (build A's) sources, you can ensure that build B will start only after the one it depends on (build A) is run and finished
Configuring Finish Build Trigger:
finish build trigger triggers a build of current build configuration if a build of selected build configuration is finished
I have project configured in Jenkins that polls an SCM and begins a build when a change is posted. There is a post build action to build another project. The question I have is, the project that is being built afterwards has its own parameters. How do I know which parameter is specified when the post-build action triggers? Right now if if I use 'Choices', is it just picking the first one? How do I have it pick other ones?
OK, let's take it one by one :)
If you want to see which parameter were used, You can install this plugin: Show Build Parameters Plugin
If you want to trigger a build with a specific parameters, use this plugin: Parameterized Trigger Plugin
The group that I work in has standardized on Jenkins for Continuous Integration builds. Code check-in triggers a standard build, Cobertura analysis and publish to an Artifactory SNAPSHOT repo. I've just finished adding a new target to the master build file that'll kick off a Sonar run but I don't want that running on every check-in.
Is there a way to schedule a nightly build of a specific build target in Jenkins? Jenkins obviously facilitates scheduled builds but it'll run the project's regular build every time. I'd like to be able to schedule the Sonar build target to run nightly.
I could, of course, create a separate Jenkins project just to run the Sonar target on a schedule but I'm trying to avoid that if I can. Our Jenkins server already has several hundred builds on it; doubling that for the sake of scheduling nightly builds isn't very desirable. I looked for a Jenkins plug-in that might facilitate this but I couldn't find anything. Any suggestions?
Here's one way to do it, if you are ok with triggering the build using cron or some other scheduling tool:
Make the build parameterized, and use a parameter in your build file to decide if the Sonar build target should run or not.
Trigger the build remotely by HTTP POST:ing the parameter values as a form to http://[jenkins-host]/jobs/[jobname]/buildWithParameters. Depending on your Jenkins version and configuration, you might need to add an Authentication Token and include this in your url.
Authenticate your POST using a username and password.
wget --auth-no-challenge --http-user=USERNAME --http-password=PASSWORD "https://[jenkins-host]/job/[jobname]/buildWithParameters?token=<token defined in job configuration>&<param>=<value>&<param2>=<value2>"
I am also looking for a solution for this. My current solution in my mind is to create 2 triggers in the regular build, one is the nightly build, another one is Polling SCM
In the sonar plugin configuration, it has the options to skip the builds triggered by the SCM change. Therefore, only the nightly build will start a sonar analysis.
I didn't get a chance to test it now, but I suppose this will work.
Updated on 12/19/2011
The above solution doesn't work if the sonar analysis is invoked as a standalone build step. To make the sonar analysis run conditionally, you could use the following 2 plugins:
Conditional BuildStep Plugin - this allows the sonar analysis to be run conditionally
Jenkins Environment Injector Plug-in - this allows you to inject the variables to indicate how the build is triggered.