How can I restrict automatically running dependent build configurations?
I have a pipeline:
Build
Stage
Release
Those are different configurations chained using snapshot dependencies. However, by default when a Teamcity configuration is run, it checks all the snapshot dependencies and then re-builds those which are not suitable.
Instead, for example, I want the Stage configuration to fail when no suitable Build snapshot dependency is found. (i.e. it should be impossible to run the Stage build without there first being a Build ready).
All I can find in Teamcity is configuration about how to handle situations where the dependency build fails, which is not what I need.
Thanks
When you declare a new Snapshot dependency, inside the options you have a dropdownlist for "On failed dependency"
Default value is: Run build, but add problem
Instead, you can set: Make build failed to start, or Cancel build
Related
We have several jobs on jenkins that are running on hierarchical dependencies on each other.
Lets say, Job2 has a dependencies on the Job1 for the pom.xml version.
so whenever we have changes at the end of sprint for Job1, we are in need to change the versions of the pom on the dependencies inside the Job2 before releasing the artifacts at the end of sprint, so this might not handy if we have Job3, Job4, Job5 that are depending on the version of Job1. we need to change all the version of Job1 on all the pom.xml of all the Jobs that is dependent on it.
So the question, are there any ways to solve this, probably using jenkins env variables? need a helping hand how to perform it based on the issues above.
Thanks.
You can use jenkins Parameterized Trigger Plugin for passing variables to the downstream projects. Plugin wiki got detailed explanation.
So you have dependencies amongst your internally developed artifacts. During development you want to depend on the latest snapshot of those artifacts, but a release build shall depend on the latest release version of those same artifacts.
This can be achieved with Jenkins and Maven. Set up your release build job like so:
Add a "Pre Step" section of type "Invoke top level Maven targets". In this step you run the targets versions:update-properties scm:checkin to update your internal dependencies to point to the latest release version.
In the main build step do the release: release:prepare release:perform -B. This builds the release version, increments the version number to the next snapshot version, builds that next snapshot version and checks this back into scm.
In a "Post Step" run the targets of the Pre Step again (with allowSnapshots=true) to update your dependencies to reference the latest snapshot version.
Examples:
NOTE: For this to work all jobs have to hit the same Maven repository. Locally on the Jenkins server or your corporate Nexus.
Since you will have the required version at the end of execution of Job1, export it as environment variable or store it in some of the file on build server like
pom_version=1.1
Now when triggering all the downstream jobs, set the parameter of jobs as "pom_version" and either pass this file to pick the required key/value or set the value in pre-defined parameter.
After that, make sure all of your downstream jobs are configured as parameterized with parameter "pom_version"
At the moment I have a project, lets call it mightymouse. Mightymouse POM is a multi-module project for mightymouse-web and mightmouse-backend.
Both of the sub modules have tests. In my situation, the mightymouse-web project compiles, test, package, install, deploys first. Then then -backend project goes through, only to fail during the integration-test stage. (Yet, it still goes through to the deploy stage).
The Jenkins job is setup to execute mvn clean deploy.
Question: Is there anyway to prevent Maven from going all the way to the deploy step on any module failing it's tests?
By default, a maven multi module build also uses the fail-fast option
--fail-fast - the default behavior - whenever a module build fails, stop the overall build immediately
Moreover, by default the maven-failsafe-plugin already fails as soon as an integration test fails via the testFailureIgnore option
Set this to true to ignore a failure during testing. Its use is NOT RECOMMENDED, but quite convenient on occasion.
User Property: maven.test.failure.ignore
Default: false
Note that the maven-surefire-plugin has the same for unit testings.
Hence, by default a multi-module build should stop as soon as a test fails (unit test or integration test), no further module would be built and not further maven phase should be invoked.
However, a Maven Jenkins job (and not a freestyle Jenkins job invoking Maven) set this option to true by default and hence the build would not fail, it will keep on and deploy, while the job would be set to UNSTABLE and not SUCCESSFUL (but still deploying).
As such, you could change your maven invocation in your Jenkins job to:
mvn clean deploy -Dmaven.test.failure.ignore=false
Overriding thus Jenkins default settings and meeting your requirements.
I have build configuration in TeamCity with automated tests. I want to run this build configuration in the loop: when one build was finished, new build is started. I can not configure 'Finish Build Trigger', because it is necessary to create snapshot dependencies for it, but I want to run tests for the latest version of code each time. How I can configure such loop?
From your question:
I can not configure 'Finish Build Trigger', because it is necessary to
create snapshot dependencies for it
Actually, it is NOT nescesary to have a snapshot dependency for a "Finish Build Trigger". You will, however, get a warning saying that "There is not snapshot dependency on the selected build configuration", but that will not keep you from triggering on a selected build.
From Teamcity Documentation:
If there is no snapshot dependency, the following limitations exist:
it is likely that a build of the build configuration being triggered will not have the same revisions as the finished build
even if both configurations have the same VCS settings
if a build configuration with the Finish Build Trigger has an artifact dependency on the last finished build of the build
configuration specified in the trigger settings, there is no
guarantee that artifacts of a build which caused build triggering
will be used, because, while the triggered build sits in the build
queue, another build may finish
the build triggered by the Finish Build Trigger will always be triggered in the default branch even if the finished build has some
other branch
I do recommend to select the "Trigger after successful build only" checkbox since you are running unit tests.
I'm making a case for moving our builds from Maven to Gradle. Below are a few of the Maven command-line options my team finds useful. What are the Gradle equivalent choices?
-am,--also-makeIf project list is specified, also build projects required by the list
-amd,--also-make-dependentsIf project list is specified, also build projects that depend on projects on the list
-o,--offline Work offline
-pl,--projects Build specified reactor projects
instead of all projects
-rf,--resume-from Resume reactor from specified project
Maven Examples:
I only want to build the sub-project I'm working on and its dependencies.
mvn install --also-makeIf --projects :my-sub-project
After fixing an build issue, I want to start the build from the point of failure.
mvn install --resume-from :my-sub-project
I don't want to download external dependencies from an central repo.
mvn install --offline
Here are some rough analogues:
-am: buildNeeded (This triggers a full build of all upstream projects; building those parts of upstream projects that are required to fulfill the command at hand is automatic in Gradle.)
-amd: buildDependents
-o: --offline
-pl: :subproject1:build :subproject2:build
-rf: No direct analogue (not reliable, wouldn't work for parallel builds, etc.), but Gradle's incremental build will get you to the "resume point" quickly.
Note that Gradle's core concepts differ significantly from Maven's. To give one example, in Gradle build order is solely determined by task relationships, and there is no such concept as an execution dependency between projects. Due to these differences, some Maven features aren't necessary or useful in Gradle, some you get for free, and some come in a different form.
When I build my application with maven, I run mvn clean install. As a part of the install lifecycle, I run appengine:devserver_start from Google's GAE Maven plugin. This appears to be already bound to a step in the lifecycle and therefore it reruns some build steps from the beginning, even though me running mvn install did those. For example, the resources step is rerun. I had my own Java script run to download the latest resources for my build. But because of appengine:devserver_stop, I need to uselessly run this cript again because the resources step is re-executed.
I can think of two ways I can avoid this, but I'm not sure how to configure both ways. The first would be to somehow skip re-running build steps that I've already run. The other way would be to change the Maven POM properties just for the plugin execution. I have a Maven property set, either to true or false, that I can use to set the skip setting for the Java script I use during resources (because I run this script using the exec-maven-plugin). Think of this as a Maven property that can be set with the -D flag. Can I have this property changed just for the plugin?
If you are having trouble thinking about my scenario, consider what happens when you run mvn compile install. All build lifecycle steps until compile will run, then all compile steps until install will run, including compile.
A common/easy way to solve this kind of problems is to use maven profile. Just create a new profile that includes the plugin with preferred phases.
You should probably don't fight with it and just run clean appengine:devserver_start instead of clean install. Read my answer here for a more detailed explanation:
https://stackoverflow.com/a/17638442/2464295