Continuous integration is a critical part of the development lifecycle move changes quickly from code through testing and packaging to deployment. These steps apply to TeamCity, but the work is really performed in docker, so could be done on nearly any CI:
It’s challenging to expect the TeamCity build agents to be up to date with the latest runtime. If you can’t count on that, then running command line tasks with Docker is your best bet.
First, the build. Add a “command line” runner. The working directory on the agent will be the location where the source is checked out, so you’ll need to attach this directory to a docker container with the
-v option. Then within that container, you’ll need to run the
dotnet commands, so the container needs to be based off the SDK images provided from Microsoft. The latest image at time of writing supports the msbuild project file format.
To actually build, you need to run a
bash command to
- Change to the directory that is mounted from the host (the build agent’s working directory).
- Restore dependencies with
- Build the project or solution with
- Test the project with
- Build a nuget package with
All of that can be done within the same container using the following command line:
docker run -v `pwd`:/src --rm -i microsoft/dotnet:sdk /bin/bash -c "cd src; dotnet restore && dotnet build && dotnet test mytestproject/mytestproject.fsproj && dotnet pack myproject/myproject.fsproj"
Once executed, a successful build will result in a nuget package under the working directory, in this case, at
&& chains commands together upon success, so, for example, if the tests fail, the package won’t be produced. The container was started with
--rm and so it will be removed upon exit of the command, cleaning up any build artifacts. An additional build step can publish that package to a nuget repository.