I have a scenario where I use Teamcity to trigger on some VCS changes, initiating a build and release procedure.
The build config has a couple of steps pretty much broken down to:
1 Get dependencies
2 Build solution
4 Run tests
5 Build specific projects so they are deploy-ready
6 Build software installer
I’m now working on implementing Octopus to automate our deployment and delivery work and will thus need to revise some steps as well as get Octopus involved.
So far, I’ve tested my very barebone Octopus server and tentacle together with my Teamcity server by enabling Octopack in my “Build solution”-step. First, I simply published to my Teamcity project Nuget feed, but soon realized that it is probably better to push to my Octopus server’s nuget package repository since I didn’t seem to have any control over the Teamcity nuget feed. The problem with this approach is that the nuget packages are packaged and shipped as soon as the solution build succeeds, whether the tests fail or not in the subsequent steps doesn’t matter at all.
I suppose my question is how I should approach this, should I have separate steps for each VS project that has Octopack installed and enabled (makes a lot of steps in the Teamcity buildconfig) or should I add another “Build solution”-build step which would redundantly build the solution again, where I activate Octopack, after all the other steps have finished?
Is this solvable by a manual MSBuild buildstep with command line arguments?