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?
Hi Yousif, thanks for getting in touch
Yes, I would expect if you’re doing the build/push before running tests, then your package would get pushed before the tests have run.
I would suggest rather than using Octopack, to use our TeamCity plugin and run the Octopus Pack step at the tail end of your build plan (or, at least, after the test step).
Hope this helps!
Hi Jason, thanks for your reply.
I’m using the Teamcity Plugin already, and I did look slightly at the OctopusDeploy: Pack runner type. However, it seems to require one build step for each package that I want to build? Is this correct?
Yes, that’s my understanding of it, yes. One Pack step per package.
All right, thanks. I think my solution will be to run another “Visual Studio Solution” build step with OctoPack activated but with the target “Build” rather than “Rebuild” as is the case in the original build step. This way nothing will be rebuilt, and I can trick OctoPack into packaging all the packages in one step. Bit of a hack, but I’d rather not have that many separate build steps. Would it be worth to add a feature request of a new Build runner to the teamcity plugin that does the same job as activating Octopack when building a solution, i.e. packaging all projects where OctoPack is installed as a NuGet package? Correct me if I’m wrong but usually, one would want to build the projects/solution before running tests and other steps, but not create the packages until all tests and further steps have also passed, right? In that case, a build runner that does all the packaging at the end should sit nicely?