Using bamboo v5.7 with msbuild v12, how do I fail a build if there are any static code analysis warnings? We do have our projects all set to treat all warnings as errors so the project itself doesn't build, but bamboo is not detecting this and continues on.
This seems basic, what might I be doing wrong?
The simple answer is you are doing nothing wrong, nor are you missing anything.
While it seems like basic functionality, Bamboo's MSBuild task currently doesn't support reading, reporting or failing the build on Warnings or Errors. The task only fails because MSBuild (or XBuild if you are using Mono) returns with an error code when a compiler error occurs.
Also, MSBuild doesn't actually support failing on all warnings either, as you can see here.
You have a couple options.
You can use one of the options in the referenced post
You could roll your own MSBuild log parser plugin using Atlassian's Plugin SDK.
You could make a simple script that is executed after the build, reads the logs and returns a non-zero integer if there were compiler warnings.
You can vote for the issue in the Atlassian Jira and also for the related issue for parsing build details.
Whatever your solution, I hope you share it with the many of us that have run into the same problem. It seems to be something quite common, so I was surprised there wasn't an issue already open for this in Atlassian's Jira instance
For VS 2008 and later, a new project setting was added for this. See this link.
We build our solution using msbuild 4.0 from TeamCity. Our continuous build uses up quite a lot of resources, both on the build machine, and on our central signing and obfuscation servers. One thing I've noticed is that even when a project fails to compile, the build continues, and other projects that do compile get signed and obfuscated.
Is there some way to make the build halt as soon as something fails?
The MsBuild task actually supports a parameter StopOnFirstFailure. However, I can't seem to get it to have any effect.
Can I use this feature to do what I need? I'm prepared to edit e.g. the Microsoft.Common.Targets file on the build servers.
I found this answer on StackOverflow that involves emitting a proj file from the solution and then editing it. I guess I could automate that process on our build servers, but it seems a lot of work to achieve a fairly basic requirement.
I ask this question because I find the the community contributions to the various build engines (like MSBuild and NAnt) do include all the tasks that promote for CI servers, like getting versions from source control, cleaning folders, changing build numbers, sending emails, etc...
Is it only because it "listens" to the changes happens on the source control repository? what else am I missing?
Grzegorz Oledzki linked a good resource for finding the differences between multiple CI solutions, but it should be noted that the intent of MSBuild is to specifically turn code into binary and is used by CI software to build the source. It's true that it can do other things but most of its tasks lie closely within that realm.
In addition to what you mentioned about listening to the repo, some CI servers can do all kinds of things like^1:
multi-agent building (not just multi-core, msbuild can do that, but multi-machine)
monitoring build status
notifications (e-mail/sms/rss/whatnot)
assigning blame for broken builds
administrative features
supporting XFDs (extreme feedback devices)
automated deployment
And generally all from a handy UI.
1 Not all CI software will have all of these features, it is by no means meant to be exhaustive and there is some overlap.
I believe CI (Continuous Integration) feature matrix will answer all your questions about particular CI providers and their capabilities.
Wow there are just so many answers to this. As for what a CI system can do that a Build Script can't do other than listen to your Version Control System... Well for starters systems like TeamCity can let you first test your code on the build server and then check it in if it passes all the tests for starters.
I highly recommend using a CI server but I prefer to keep all of the build logic in a MSBuild file and all of the who to notify when it fails etc. in the CI server. Keeping the logic in the Build file helps you to reproduce the build on your own machine and makes it simple to set up new projects in the CI server or to change how the CI server builds the project
Our msbuild process creates a variety of zip packages for deployment (mostly web sites, but other things as well). We have a variety of recurring problems that keep sneaking back - files included that shouldn't be, missing resources. This screams for automated validation. The criteria to test for are simple
Validation of foosite package:
Resource files are present.
No test result files, obj files, or other build artifacts
And so forth.
Ideally, I could use nunit or mstest, which everone is familiar with. Msbuild knows where the packages are. We have a lot of packages, possible concurrent builds on different branches. Ergo, the location of the packages and names of the packages are not deterministic - so the tests don't know where the packages are.
What is the simplest way to feed msbuild information to mstest or nunit? The answer to this question would one possible answer, however, that question got architectural advice instead of an answer. I know this isn't a unit test, but the test framework is handy, anyway. I could create an exe to validate the build - but why add a couple hours to the project?
Or, do you have a better suggestion for automatically validating build packages? (MSIs, zips, whatever)?
What I've ended up doing is having a bunch of custom MS build tasks which spin up a virtual machine on Virtual Server, copy the MSI onto the machine, silently deploy it and then validate against it. I used PSExec to start the MSI. It could then use the MSTest command line runner to use MSTest and run your test bits.
This is probably overkill for you, but using a VM allows you to start clean and not be affected by any previous installs on your dev box.
If you want a fast fail, like a unit test, then I suggest you create unit tests against your packages. Such a test would unzip the .ZIP packages, and run some asserts against the contents.
You could even use some TDD techniques against the packages. For instance, if you have a deployment fail because a particular file is missing, then write a unit test that fails because the file is missing; change the build so that the file is present; then make sure the unit test succeeds.
But in general, deployment issues are broader than that, and I echo the suggestion from blowdart. Deploy into one or more virtual machines, then run automates tests over the deployed environments. These tests would not only test for simple things like was there an error returned during the installation itself; they would also check things like were the IIS virtual directories set up correctly, with the correct properties and contents, and does the web site basically run.
I'd use several different virtual machines to test different deployment scenarios: one for a clean deploy; one for an upgrade from version .-1, etc. It's possible that the same, or similar IVT tests could be run for each environment.
Even if you can't do this all at once, the thought process involved in this exercise should lead to a more formal definition of what your deployment environment really is. You this will be helpful when you get a chance to embody this formal definition in actual tests.
At home, I use CTRL+SHIFT+B or F7 or whatever key sequence initiates the build for my build tool. At work, this doesn't quite cut it.
At my first job (an internship) we used a product called Visual Build, which I have come to like very much. It's the best build tool I've ever worked with. The down side here is that it's not free.
At my latest job, I came in knowing literally nothing about Ant. Now, unfortunately, I've become deeply involved in our build processes, and cannot extricate myself. It works, yes, but after coming from Visual build, it seems like it's fighting me every step of the way. Yes, it's free, but we're not trying to be a free-software-only development company or anything.
I've never looked in to make or any other build tools, so I don't really know what else is out there.
Has anybody ever seen or had experience with Visual Build? Mostly I'm fond of a few key things:
it has a GUI
it runs arbitrary VBScript without the need of a compiled class
you can step through the build process, or start from anywhere in the middle.
Are there any free build tools that have this? Is there any way to convince people that it's worth it to move on? It's 2008. We use IDEs to develop, why not (IBEs) to build?
Edit: I'm mostly looking for an answer to my last questions; Is there a solution with a built-in GUI that I can use for free?
Not very sophisticated, but we use a set of batch files. And that works great.
We use FinalBuilder - I think it's very similar to VisualBuild, though I've not used the latter.
It does run from the command line, and you can integrate it with CC.Net if you want.
For Java projects we use Teamcity, sort of cruise control like, but you can also do a remote run, i.e. you send your changes to the server, it builds and does unit tests, if everything works ok, THEN you checkin, very nice build tool and free for up to 20 build configurations.
For our Visual Studio 2005 projects including packaging the final exes and dlls with InstallShield and putting them up on a shared server we use Final Builder, it's not free, but it is very easy to use and get started with.
We also telnet out (from FinalBuilder) to a number of other platforms (Unix/Linux/OpenVMS) and start remote builds by running makefiles there.
We do not use continous build, but there is a FinalBuilder Server which handles that and comes free with the FinalBuilder Professional license.
We are very happy with FinalBuilder, it's quite easy to get up to speed with and powerful enough to solve most problems.
CMake. Generates build file for KDevelop, Eclipse, Makefiles and Visual Studio (and XCode), and it really works. You can easily extend it with macros, although the programming capabilities are rather limited. It's easy to learn, and porting an existing application from Visual Studio to it is pretty easy. However, you are limited to C++/C and IIRC Fortran code.
KDE is also using CMake now, so it seems to scale very well (i.e. generation time for the projects/dependency checking is not too bad).
I am not sure this is exactly what you are looking for, but I LOVE CruiseControl.NET. I have it build my projects using the MSBuild task. It doesn't have a GUI exactly, but there is a web interface to view the results of your builds and a System Tray resident program which will alert you of the build status.
UppercuT. It's free.
UppercuT uses NAnt to build and it is the insanely easy to use Build Framework.
Automated Builds as easy as (1) solution name, (2) source control path, (3) company name for most projects!!!
http://code.google.com/p/uppercut/
Some good explanations here: UppercuT
Going back to the keystrokes thing for a sec, I found Hoekey which the CTO loves. I don't use it myself, but as a way of assign keystrokes to things, it's pretty good.
I know nothing of Visual Build, but from your description it sounds like it is tied to Windows and doesn't run from the command line.
If you are building Java software (I assume you are since you are using Ant), it's preferable to have a cross-platform tool. If you can run the tool from the command-line, then it is scriptable which is extremely important for automation.
Ant is also extensible and a de facto standard. Many tools that you may use (Cobertura, TestNG, etc.) provide Ant tasks so that they can easily be intergrated with your build.
I use Ant for all Java projects. Some people prefer Maven, but I'm not one of them. Ant is far from perfect (the XML syntax is a bit clunky) but it is well documented, extremely stable and pretty straightforward.
If you use a standard tool, such as Ant or Maven, you will be able to take advantage of any number of Continuous Integration products. I doubt you will find many that work with Visual Build.
Most IDEs support Ant, so they give you a GUI of sorts and your CI server will give you a web interface for doing builds.
NAnt (.NET port of Ant). Works great and is easily extensible.
For small projects I do use post-build scripts and with the support of 7z, Nsis and similar CLI tools it's doing the job perfectly for me.
TeamCity and CuriseControl works well for any projects,but here is why you would like to choose TeamCity:-
Ease of setup: During setup we found TeamCity easier to setup and use especially compared to CruiseControl. We did not need to edit XML files or massively configure individual build machines like CruiseControl.
Ease of extensibility:TeamCity stands out in its ease of extensibility too. If we find that builds are waiting in the queue too long, we can add more computers as agents. The only additional work on our end is registering the new computers with the TeamCity server and installing msbuild and subversion.
Interaction with Subversion: One can check how many and what changes were committed to subversion since the last build, who started a build etc.
I've grown very fond of scons for building C++ files. It's very straightforward and the build scripts are written in Python (which is much better than some hacked together DSL IMO).
Ant or Maven are great little build tools.
And if you want to automate the build process there are some great tools like TeamCity and Bamboo.
Personally I use Makefiles for pretty much everything because they are simple as hell. But in my work, I'm forced to use ant.
The main problem I have against ant is that XML makes it hard to read and understand, even with the correct indentation. On the other hand, the verbosity of XML can help when reading someone else's ant file, but still makes it a PITA when the file is more than a few tens of lines.
As for having a GUI to build... I've always felt that's a minus rather than a plus.
Maven is the best for me because it handles the project dependencies