I'm having trouble with an MSBuild script as it's executing correctly, but in TFS Build Explorer it reports a Fail (red X icon). However, despite all the builds reporting failed, if I examine the logs, they look fine, and end with :
Done building target "EndToEndIteration" in project "TFSBuild.proj".
Done Building Project "C:\Builds\EDRM Development\CI_Development_IW471_UserGroup_CG3\BuildType\TFSBuild.proj" (EndToEndIteration target(s)).
Build succeeded.
0 Warning(s)
0 Error(s)
What exactly is Build Explorer using to determine the success of the build script ?
The script itself is using the MSBuild Extension Pack (from CodePlex) to build a solution containing 40+ VB6 projects. So that it can be run by team build, i've implemented target EndToEndIteration, with the build target as a 'DependsOnTargets'. EndToEndIteration is the only one of team build's targets that I have implemented in the script (it appears to be the only mandatory one ?).
When i run the script from the command line it reports success also, so it's only Build Explorer that's indicating a failure.
Any ideas why this is happening ?
The success of the build is determined by ALL Tasks ended with success pattern (if one fails it may be consider as partially succeed build, but the icon will still remain as a failure icon with small green success icon:)
Try to look at build log's, because it seems, that some pre or past run steps are failing (unable to copy sth, etc). The easiest way is to determine where the problem is, is to schedule the build from Visual Studio with maximum verbosity level for each Task.
Thanks for the reply. All tasks were ending with success.
I've just found out the solution though, so I'll add it here.
As I'm building a VB6 solution (comprising 40+ projects), I'd created a pure msbuild script, that i'd originally been running from the command line. To use it with team build for CI, i'd added a target "EndToEndIteration" as this is the only mandatory target for a new msbuild script in team build (i.e. a script not created via TFS's create build script wizard). This results in the problem above, where even if the script executes perfectly, build explorer still reports failure.
The solution is to create a build script using the TFS wizard (for any .Net .sln file - it doesn't matter - the reference to it will be deleted). Then take a copy of this tfsbuild.proj file and strip out the details relating to the .Net project and paste in your msbuild targets. Then implement target "CoreCompile" to initiate the targets you pasted in.
Related
I'm trying to get SonarQube setup on our tfs build server and it keeps stopping the scan after pre-processing succeeds. I'm using the MSBuild.SonarQube.Runner.exe. There are no error messages at all. No indication that anything has gone wrong. I'm not sure where to go from here. Halp?
There's nothing wrong in what you see as the output. You are just missing some bits and pieces.
The “begin” invocation sets up the SonarQube analysis. Mandatory
analysis settings such as the SonarQube project key, name and version
must be passed in, as well as any optional settings, such as paths to
code coverage reports. During this phase, the scanner fetches the
quality profile and settings to be used from the SonarQube server.
Then, you build your project as you would typically do. As the build
happens, the SonarQube Scanner for MSBuild gathers the exact set of
projects and source files being compiled and analyzes them.
Finally, during the “end” invocation, remaining analysis data such as
Git or TFVC one is gathered, and the overall results are sent to the
SonarQube server.
Source
In short, after the first command call (begin), you need to run MSBuild 14.0 and build your solution, then finish up the invocation (end) and see the analysis results in your SonarQube server, if everything went all right.
# This is part of the pre-build script
> MSBuild.SonarQube.Runner.exe begin /k:project_key /n:project_name /v:project_version
# Build your solution here
> msbuild /t:rebuild
# This is part of the post-build script
> MSBuild.SonarQube.Runner.exe end
That small script should be part of your build pipeline (using Jenkins, TeamCity, or whatever CI tool) ideally.
Hope this helps!
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 recently added a TFS build to our project, and configured it to run the automated tests that are in the project, and for some reason the build is ignoring the tests as if they don't exist!
In order to figure this out I created another solution with only a basic project from the origin code and the test project as well.
I've added these to the TFS and configured an almost equal build to this solution, and guess what? it executed the tests! it's the same tests as the original. just a copy of it.
The main difference between these 2 solutions is that the original code is a big solution with many projects, most of the projects are in some kind of a solution directory (and so does the tests project - it's inside a solution directory as well).
The difference between the TFS build definition is only that the output location of the build is set to single directory (I also tried PerProject and it worked) and in the original code it's defined to "AsConfigured" because we have some build tasks for copying dlls and such.
Has anyone encountered this problem?
Any ideas?
Thanks
TFS will look for the test DLLs in the BINARIES output folder location. You need to configure your 'build tasks for copying DLLs' to ensure your test DLLs are copied to this location.
Test assembly file specification
Specify the binary files that contain the tests that you want to run. Leave the default value (**\**test*.dll) if you want the build agent to search recursively for any .dll files that match *test*.dll in the binaries subdirectory of the build agent's working directory.
TFS2013 — http://msdn.microsoft.com/en-us/library/ms253138.aspx
TFS2012 — http://msdn.microsoft.com/en-us/library/ms253138(v=vs.110).aspx
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
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?