Recently, I started researching tools and services for the build automation. Being a long user of TeamCity and currently Travis CI (also had some experience with Jenkins, AppVeyor and VSTS) I wanted to find out what else is there. Then I realized that there’s a build server built into BitBucket, thus I decided to give it a go.





BitBucket Pipelines is a part of BitBucket cloud and hosted repository either for Git or Mercurial projects. There’s no need to install or download anything – just click enable Pipelines and that’s it. What I wanted to achieve is the following, a rather typical scenario – after each commit to the repository, assuming that the specific Git branch was updated, the service should build the app, test it and then build a Docker image and publish it to the Docker Hub or any other registry e.g. Azure Container Registry.

And I wanted to do it in the simplest way possible – as much as I like TeamCity, there’s a lot of things required to get things done, in opposite to e.g Travis CI. Therefore, I really wanted to define my overall build flow in a single file if possible and just don’t care about anything else. So this is what my bitbucket-pipelines.yml eventually looked like (which has to be placed in the root of the repository):

image: microsoft/dotnet:latest options: docker: true pipelines: branches: master: - step: script: - dotnet restore - dotnet build - dotnet test - docker login --username $DOCKER_USERNAME --password $DOCKER_PASSWORD - docker build -f Dockerfile.production -t myrepository/myapp . - docker push myrepository/myapp develop: - step: script: - dotnet restore - dotnet build - dotnet test - docker login --username $DOCKER_USERNAME --password $DOCKER_PASSWORD - docker build -f Dockerfile.development -t myrepository/myapp:dev . - docker push myrepository/myapp:dev 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 image : microsoft / dotnet : latest options : docker : true pipelines : branches : master : - step : script : - dotnet restore - dotnet build - dotnet test - docker login -- username $ DOCKER_USERNAME -- password $ DOCKER_PASSWORD - docker build - f Dockerfile . production - t myrepository / myapp . - docker push myrepository / myapp develop : - step : script : - dotnet restore - dotnet build - dotnet test - docker login -- username $ DOCKER_USERNAME -- password $ DOCKER_PASSWORD - docker build - f Dockerfile . development - t myrepository / myapp : dev . - docker push myrepository / myapp : dev

As you can see, there’s an easy way to access the environment variables. Both, the DOCKER_USERNAME and DOCKER_PASSWORD were defined as the secured variables within my account settings in the repository, as I do not want to push the username or password to my repository at all. And if you’d like to define some environment variables in the configuration file, you can do it easily using the export keyword, for example like this:

pipelines: branches: master: - step: script: - export DOCKER_USERNAME=myapp - export DOCKER_PASSWORD=secret 1 2 3 4 5 6 7 pipelines : branches : master : - step : script : - export DOCKER_USERNAME = myapp - export DOCKER_PASSWORD = secret

And of course, you can access the system variables like the name of the branch using BITBUCKET_BRANCH or hash of the commit BITBUCKET_COMMIT that might be especially useful for tagging the project versions.

Pipelines builds are really fast and for me, that really matters. So where’s the catch? Using the free version you can access only 50 minutes monthly for the build services, however for 10$ monthly (2$ per user starting from 5 users) you can already make use of 500 minutes, so you should be fine.