After moving a few files to new directories, our main TeamCity build started complaining about a missing artifact path("Artifacts path 'some/path/*.tar.gz' not found"), and dependent builds would fail. In my opinion, dependent builds should not even have been started, because the main build failed - but TeamCity reports those builds as successful (green). This doesn't exactly make finding the problem easier, and I would prefer that the build go red if the artifacts cannot be published. How?
You can add new failure condition when output logs matches regex:
Artifacts path .+ not found
This depends on 2 factors
The part of the code which publishes artefacts did not publish a non-zero exit code that teamcity could translate into a build failure. You should probably open up a ticket for them
You can also define your custom build failure conditions in the "Build failure" settings. You can cause the build to fail if artefacts cannot be published
Related
Here's my project's TeamCity configuration:
TC calls my script (FAKE - F# Make) to build & test my project.
As the final step, the same script creates a NuGet package.
Then I use TC's "Build Failure Conditions" mechanism to see if e.g. the total number of unit tests is not less than in the previous build.
Even if my build fails while running the last step, the NuGet package is published as an artifact.
I guess this is not the case - the build failed, so anything it provides shouldn't be considered as reliable.
I've found a similar question asked ~5 years ago:
How do I set TeamCity to not produce build artifacts when the build fails?
which says there was no built-in mechanism in TC to support that. Has anything changed during this time ? Can't find anything on the net.
I use TeamCity 9.0.
My only solution to this would be to separate out the deployment of the package to NuGet as a separate build configuration. That way, you can setup your dependencies/triggers within TeamCity so that it never deploys if the build step you have in place fails.
The artifact will still be created on the TeamCity side, since, as you stated, I cannot find a way to prevent that if the build fails. However, your actual NuGet deployment will never execute if setup this way because the dependency will prevent it with the build failure.
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 am using TeamCity as my CI server.
I have defined three Build Steps. One builds my project from the .sln file, one runs tests using MSTest the final one packages up some of the dlls and exes the project produces into a deployment package.
Currently even if some tests fail the deployment package is still created. How can I stop Team City from processing further Build Steps if one has a problem?
Seems I am not the only one with this problem.
http://youtrack.jetbrains.net/issue/TW-12194
I am not sure how to adjust my scripts to know if things upstream have failed.
In the build conficguration genneral settings page, there is "Fail build if" section.
There is a checkbox in it which says "at least one test fails".
Is it checked?
I've started using TeamCity personal builds, via the new Git remote run feature in TeamCity 6.5. Doing a single build works fine; I have a project that compiles from source, and I gave it a Branch Remote Run trigger.
However, it looks like TeamCity only triggers the one project that has the Branch Remote Run trigger applied. I have several unit test projects, set up in a chain with Finish Build triggers, and none of these get run. Furthermore, if I try to start a custom build of one of these unit test projects, I can't use the artifacts from my personal build: I can only pick artifacts from one of the 'official' builds.
Can I get TeamCity personal builds to work with build chains?
With the setup that you have (snapshot dependencies and finish build triggers), you can achieve build chaining by submitted your personal changes to the builds you are looking to trigger. For example, if you have projects A and B where B depends on A - run the remote build against project B and A will be triggered first and B will be added to the queue. Both of these builds will have your personal changes.
If you are using the TeamCity Visual Studio plugin you can select which builds you want to send your changes to and you just need to tick the box for B instead of A.
The finished build trigger won't be fired, but the build chaining means that A must be built first.
More info - http://confluence.jetbrains.net/display/TCD7/Build+Chain
(You have tagged TeamCity 6.5, but 7 has now been released so I have included the documentation for the newer version)
I suppose you should setup your chain not with Finish Build trigger, but with "Snapshot dependencies" feature of TeamCity. And, setup artifacts dependency basing on the snapshots.
Please read about snapshot dependencies in TeamCity here.
How do I set up TeamCity so that it does not publish build artifacts if the build fails because a unit test failed? I'm pretty sure it worked this way prior to version 6.0, but since upgrading to 6.0 it always produces artifacts even if a test fails. I have "Fail build if at least one test failed" checked.
We had an outage with the e-mail notification and I didn't know we had a build problem because it continued producing artifacts.
Please watch/vote for this issue: http://youtrack.jetbrains.net/issue/TW-12194