I spent the past two days playing with setting up TeamCity on Azure. This is just a poc more than anything else, but it’s always fun to do something new. I had to fiddle about with some things that didn’t work as expected, so here are some notes to remember what I did.
In this post, I’ll modify the pipeline from the previous posts to use a Docker registry powered by AWS ECR (Amazon Elastic Container Registry).
In this post, I’ll add code coverage to the build pipeline and configure TeamCity to break the build if the code coverage drops.
In this post, I’ll add unit tests to the example application that I’ve been fiddling around with in the recent posts.
In this post, I’ll add some automated browser tests using PhantomJS and WebdriverIO.
In this post, I’ll implement a post deployment check that waits until the application is running with the expected version.
Continue reading Waiting for the correct version after deployment
In the post about versioned artifacts, I was using a custom text file named
image-tag.txt to share the image tag between build configurations. The commit stage evaluates the image tag and produces the
image-tag.txt artifact, which just contains the version e.g.
After the post about the versioning script, the build number of the commit stage and the image tag where identical and they were following semantic versioning.
In a more recent post, I’ve configured a build chain in TeamCity, in which all build configurations share the build number of the Commit Stage. This means that all build configurations have the correct image tag information implicitly, as their build number. This makes the
image-tag.txt artifact obsolete.
I have therefore removed the
image-tag.txt artifact and I’m using the implicit configuration parameter
%build.number% wherever I need it. The pull request is available here.