I have setup TeamCity 7 to automatically build and publish artifacts. This works fine.
As part of my build step, I have a ‘Create Release’ build step:
create-release [omitted for brevity] --version=%build.number% --packageversion=%build.number% "--releasenotes=Automatic release created from TeamCity. Git version %custom.branch% / %build.vcs.number.1%"
This is supposed to create a release on Octopus Deploy when the build has succeeded.
Unfortunately, this does not work because we try and create the release (for the being-built build) before the build has finished (or at least published the artifacts). Octopus cannot see this build (yet) in the NuGet feed from TeamCity.
How am I supposed to automatically create a release from this build on Octopus Deploy, using TeamCity?
There does not seem to be a way to run a build step after the NuGet feed (hosted by TeamCity 7 server) publishes the package for Octopus to consume.
Hmm, that kind of sucks to have to create 2 builds. I have many builds and deploys. I’ve just started to convert all the deployments into octo and have run into this issue. It seems like Octo should have a switch to not verify the nuget package. Then you can use the packageversion switch to tell it what version.
I was wondering whether we could remove this dependency, and have the Create-Release command accept a ‘Delayed Attempt’ flag, or something, so Octopus receives the deployment job for Version X (which is still being built), and will deploy it when it is made available?
It’s very strange TeamCity have no post-build-complete hook point!
I’m still thinking about this. I really don’t want multiple build configs.
I’m considering having a build step fork an executable that sleeps for 30 seconds at the end (the ran executable by TeamCity will return immediately, to not let the build block).
When 30 seconds have passed, just do the create-release command, as it (should be) ready by now, but thats a bit hacky.
Added a Command Line build step to the end of my TeamCity build steps (see below)
When the DelayRun script runs, it forks itself and returns immediately (so the build step passes in TeamCity immediately). We then wait (as per below) 60 seconds, then run the create-release command.
The 60 seconds seems to be a good enough enough time between when TC finalizes the build (right after the DelayRun command returns after forking), prepares the artifacts and publishes them to the nuget feed.
When the create-release ends up running, the build has had time to have its artifacts published to the nuget feed so Octopus can see them.
Command Line Script:
fork 60 c:\utils\octo.exe create-release %octo.initparam% %octo.extra% --version=%build.number% --packageversion=%build.number% "--releasenotes=Automatic release created from TeamCity. Git version %custom.branch% / %build.vcs.number.1%"
Where:
%octo.initparam%: Is defined as “–project=project in Octopus” --server=… -apikey=…
%octo.extra%: Is blank (or --deployto=…) on a per-configuration basis
%custom.branch%: Marks the custom branch being checked out (eg, master, develop, …)
I hope this is helpful to someone get setup easier.
Ideally Octopus would check for new builds (as Paul suggested in chat) and automatically deploy based on configuration options.
Awesome idea! I took it one better and built it into Octo itself. Just add a --delay=00:01:00 flag and it will do the same thing that your program did.
Paul, let me know if you want a merge request. Attached is a build with the flag added.
This just meant that right now TeamCity told Octopus to deploy the release for Version B (and soon to be Version A), instead of leaving it at Version C (the latest)!
Eeek!
Is there a way to overcome this limitation, ideally TeamCity shouldn’t run the deployment step if its not running the latest source release (and is merely backdating missed revisions that have only now been pushed).
I had this same problem even though I am using 2 build configs just like Paul mentions. The problem stems from the fact that my build produces 24 NuGet packages as artifacts totaling about 275MB. When the build finishes those artifacts have to be transferred from the build agent back to the build server and then published to the TeamCity NuGet feed. I solved the problem using a delay also however, rather than forking off and returning success to the build server immediately, I built the delay right into my Command Line build step like this:
@@@
echo Sleep for 30 seconds to ensure latest version of packages have been published.
ping -n 30 127.0.0.1 > null
@@@
This just pings local host 30 times and pipes the output to null creating a 30 second delay before the next command is run. The next command, of course, is my call to Octo.exe to create the release. The advantage of this method is that any output from Octo.exe is included in my build log and if the Octo.exe call fails it will fail my build and TeamCity will notify me. I also make use of the -waitfordeployment flag so that if the deployment fails it will fail my build step and I will get a notification from TeamCity and I can even use the TeamCity feature to automatically retry a failed build to retry the deployment.
