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
) 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.
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 -f Dockerfile.production - docker login --username $DOCKER_USERNAME --password $DOCKER_PASSWORD - docker build -t myrepository/myapp . - docker push myrepository/myapp develop: - step: script: - dotnet restore - dotnet build -f Dockerfile.development - docker login --username $DOCKER_USERNAME --password $DOCKER_PASSWORD - docker build -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
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
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.