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?
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.
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
I'm sure this is a dumb mistake on my part but I can't find the right answer.
I have a project that has a snapshot dependency on another project. For sake of discussion website is dependent on toolkit.
Monitoring the build folder:
c:\programs\Teamcity\buildagent\work
I see the toolkit get built and the folders all exist as expected:
c:\programs\teamcity\buildagent\work\toolkit
Then the website build kicks off and the folder above gets deleted before the website build starts.
This results in the website saying the reference couldn't be found. What setting am I missing?
Using TeamCity 7.1.2, working on getting it upgraded to 8.1 but it requires some internal evaluation first.
Don't think its a version issue. How do both of your builds know where to put the artefacts at . For ex teamcity normally builds stuff at c:\programs\teamcity\buildagent\work****\toolkit , not at c:\programs\teamcity\buildagent\work\toolkit ?
Also, if your targets are dependent upon each other across builds, (1) have you setup any artefact dependencies or (2) any process that does not read of a shared agent workspace ? or (3) forcing both builds to run from the same directory
See if both your builds are running on the same target "folder name". In case they are , deselect any option that "cleans up build targets" before they run.
Also, you might want to check your build files to see if they have any code to clean directories before they start to run
We are currently running a Jenkins (Hudson) CI server to build and package our .net web projects and database projects. Everything is working great but I want to start writing unit tests and then only passing the build if the unit tests pass. We are using the built in msbuild task to build the web project. With the following arguments ...
MsBuild Version .NET 4.0
MsBuild Build File ./WebProjectFolder/WebProject.csproj
Command Line Arguments ./target:Rebuild /p:Configuration=Release;DeployOnBuild=True;PackageLocation=".\obj\Release\WebProject.zip";PackageAsSingleFile=True
We need to run automated tests over our code that run automatically when we build on our machines (post build event possibly) but also run when Jenkins does a build for that project.
If you run it like this it doesn't build the unit tests project because the web project doesn't reference the test project. The test project would reference the web project but I'm pretty sure that would be butchering our automated builds as they exist primarily to build and package our deployments. Running these tests should be a step in that automated build and package process.
Options ...
Create two Jenkins jobs. one to run the tests ... if the tests pass another build is triggered which builds and packages the web project. Put the post build event on the test project.
Build the solution instead of the project (make sure the solution contains the required tests) and put post build events on any test projects that would run the nunit console to run the tests. Then use the command line to copy all the required files from each of the bin and content directories into a package.
Just build the test project in jenkins instead of the web project in jenkins. The test project would reference the web project (depending on what you're testing) and build it.
Problems ...
There's two jobs and not one. Two things to debug not one. One to see if the tests passed and one to build and compile the web project. The tests could pass but the build could fail if its something that isn't used by what you're testing ...
This requires us to know exactly what goes into the build. Right now msbuild does it all for us. If you have multiple teams working on a project everytime an extra folder is created you have to worry about the possibly brittle command line statements.
This seems like a corruption of our main purpose here. The tests should be a step in this process not the overriding most important thing in this process. I'm also not 100% sure that a triggered build is the same as a normal build does it do all the same things as a normal build. Move all the correct files in the same way move them all into the same directories etc.
Initial problem.
We want to run our tests whenever our main project is built. But adding a post build event to the web project that runs against the test project doesn't work because the web project doesn't reference the test project and won't trigger a build of this project. I could go on ... but that's enough ...
We've spent about a week trying to make this work nicely but haven't succeeded. Feel free to edit this if you feel you can get a better response ...
In Jenkins/Hudson, it's quite ok to have many jobs. some for doing compilation triggered version control changes, some for running (unit) tests triggered by successful builds, some for doing more tests (integeration) trigered by successful earlier tests, some for deploying, triggered by successfully passing all tests.
Look at plugins like join, build pipeline, parametrized trigger and more to help out with this.
This will also allow things to happen in parallel, by using multiple nodes. Trying to cram everything in one job is not the way to go.
I think I'm missing a valuable piece of understanding with TeamCity 5.0. Why is there a separate build runner for FxCop? I prefer that my build server run everything, at once (compile, run unit tests, FxCop, etc). The problem is, I don't see how to add more than a single Build Runner for a specific project, so it seems I have to add a second project to TeamCity with a dependency on another project that uses the sln2008 build runner, or I could simply go the long route and build everything out in MSBuild. Am I missing something that should be obvious? Is it possible to configure the sln2008 Build Runner to include FxCop code analysis?
I think most of the users want their builds with tests to be as fast as possible. Other things like coverage, code analysis, metrics most likely should not be run often. It is enough to run them once per day, because their value is statistics gathered over time.
As for multiple build runners per build configuraution feature - it is one of the most voted in our tracker: http://youtrack.jetbrains.net/issue/TW-3660?query=multiple+build+runners, it has very good chances to be implemented in the next versions.