![]() ![]() We can configure TeamCity to listen to a given GitHub repository the usual way and we can define a trigger that starts a build whenever someone pushes to the master branch of the repository. Once we’re done we can tear down the whole test setup like this Configuring TeamCity Just run the following commands in your shell Once we have all prepared we can use docker-compose to build the images and execute the tests locally. Not the most sophisticated test I agree but it server to show the idea. If this fragment is found then the test succeeds otherwise it fails. My test is implemented as a simple Bash script and uses curl to navigate to the URL web:5000/api/projects and analyzes the response and looks out for the presence of a fragment. When accessing our web API at the relative URI /api/projects it returns the following JSON content For testing purposes on the CI server this is not really needed but it came in handy while I was debugging my whole setup since it allowed me to access the web service from my browser or from Postman. ![]() Note, on lines 17&18 we declare that the container web should map its internal port 5000 to port 80 of the host. The image with a name of ci-webapi is built using the Docker file called Dockerfile and the name of the container when running will also be ci-webapi. The container web contains the code we want to test (in this case a ASP.NET core Web API). The container when running will have the name ci-tests and the Docker image from which the container is instantiated has the same name. We build this container by using the Docker file called Dockerfile.test. The container sut contains our test code. Both containers will be part of the network test and thus can access each other without the need of any publicly exposed ports. What this file basically says is that we are creating two containers web and sut as well as a network test. Let’s look at a sample (you can find the full source on GitHub). Since we now need to start multiple containers we can use Docker-Compose to simplify the task. Once the tests are executed we can just destroy (and remove) the two containers and we are left with a clean system. Those tests will be executed against the public API of the former. We can run an instance of our code in a Docker container and then run another container which contains our tests. Docker makes this really simple and convenient. Part of CI is testing the just built artifacts. To start a pair of TeamCity and Agent we need to navigate to the folder containing the above yaml file and use this commandĪfter a minute or so TeamCity and Agent will be ready to be used and I can access TeamCity as usual port 8111 of my Docker Host (i.e. Together with this Docker-Compose Yaml file I also found some better suited Docker images for TeamCity and TeamCity Agents. In doing so we can now access Docker from within the agent container and execute all operations that we normally can do on the Docker Host. We basically have to mount the Docker sock volume of the host to the container The same author suggests how we can configure our build agent to be able to use Docker and create sibling containers instead of nested containers. Thus I decided to look out for a better solution. As he points out DID has various disadvantages and side effects when used in CI. ![]() Avoid Docker in DockerĪccording to the author of the Docker in Docker (DID) solution it is actually not a good idea to use DID in Continuous Integration (CI). Further more I want to discuss how we can use Docker to test our container containing the code. In this part I want to first provide a better alternative than using Docker in Docker which has a lot of drawbacks and potential side effects. Please refer to this post for an introduction and a complete table of content. It is part of the series about Implementing a CI/CD Pipeline. This is the 3rd part of a post about using TeamCity and Docker to provide Continuous Integration. CI with TeamCity and Docker – Part 3 1 April, 2016. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |