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.
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"
I have a TeamCity project configured with 2 build configurations 'A' and 'B'. The 'A' configuration is meant to run against a feature branch and build the solution. It also publishes packages to the team city nuget feed.
I am also using the Octopus Deploy teamcity plugin to automate the creation of releases and deployments in our Octo server. Any packages published by a build configuration to the TeamCity nuget feed are not available to any build steps within the same build configuration so a second build configuration must be created to consume the packages.
As a result the 'B' build configuration is the Octo deployment step and it has a snapshot dependency to build A and an artifact dependency to build A. The artifact dependency has 'Get artifacts from' set to 'Build from the same chain'.
The build chain runs without issues when run with the teamcity vcs default branch. However the 'B' build config does not trigger when the 'A' build config runs against a feature branch. When looking at the build chain in teamcity when a build occurs on a feature branch the 'B' build config says 'Not Triggered'.
I can't find any clear solution to this problem and whether or not this is actually supported by TeamCity. It sounds like in earlier versions of TeamCity (~v7) this was not supported but that the introduction of snapshot/artifact dependencies solved the issue.
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
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 am using jenkins/hudson to make maven releases, and sometimes when the builds fails, I have no other way that manual to rollback and then start the jenkins build again. I was wondering if there is any good and configurable way of running mvn release:rollback in the end of the build dependent the result of mvn release:prepare? I mean, if the release process fails, I want to run maven release:rollback, otherwise not.
Thanks your time.
You can configure your Jenkins job to do a fresh checkout of the source code every time the job is started. So if your release fails before the creation of the release tag, you can fix the problems and just start the release again.