Infrastructure changes in Bitbucket Pipelines
This page tracks internal infrastructure changes to Bitbucket Pipelines that in rare cases might affect customer builds.
November 2017 - Docker now a service, limited to 1 GB memory
On 28 November 2017, as part of implementing docker-run support in Pipelines, we now treat Docker as a Pipelines service. This means commands executed via Docker will have a memory limit of 1 GB, and builds that enable Docker can only use two additional services per build step.
There are a very small number of existing builds that use three services and have Docker enabled that will break with this change. We have directly notified customers who have recently run builds with this configuration.
Our recommendation is to either stop running one of your services or change one service to run using "docker run" instead (YAML example). Docker run support will also give you the flexibility to start multiple Docker containers in the same build, including via docker-compose files.
October 2017 - New outbound IP addresses
On 25 October 2017, new IP addresses were provisioned for our build infrastructure.
September 2017 - Docker upgrade
On 7 September 2017, we upgraded the Docker daemon provided to Pipelines build containers, from 1.12.6 to 17.05.
Please see this ticket for more details: https://bitbucket.org/site/master/issues/14333/upgrade-docker-for-multi-stage-builds
February 2017 - New infrastructure
As of February 2017, we're rolling out changes to Pipeline's build infrastructure to provide a foundation for upcoming new features. Pipelines still executes your scripts in an isolated Docker container, and most people won't notice any change in behaviour.
There are a couple of minor differences that may affect some people, described below.
How to tell if you have the new infrastructure
You can tell if you've got the updated infrastructure by looking at the log file. The 'Build setup' section at the top will be noticeably shorter, and will no longer contain
docker run commands.
You still have the old infrastructure if you see
docker run commands in the 'Build setup' section of your log file similar to the following:
Scripts are no longer run in an interactive shell
Pipelines will continue to execute the .bashrc file as if run in an interactive non-login shell but it now behaves as a non-interactive shell. This change may affect scripts that use
stdin or have other dependencies on an interactive shell. For these few cases we recommend that you rework your scripts to run non-interactively.
This improves usage of Bitbucket Pipelines in a couple of ways:
- Commands waiting on user input will now exit and fail the build immediately, rather than hanging the build waiting for input.
- Some tools, such as Git and Maven, display download progress indicators in an interactive terminal. Now that builds non-interactively, many tools will no longer log verbose progress indicators, streamlining your Pipelines log output.
Environment variables with invalid names are no longer passed to the build container
Pipelines started requiring valid C identifiers (matching regex
/[A-Za-z_][A-Za-z0-9_]*/) for environment variable names in November 2016, preventing new invalid variables being created. However, there are still a small number of customers with old, invalid environment variables configured.
With the recent infrastructure changes, variables with invalid names will no longer be passed to the build container. Scripts that depend on these variables must be updated to use new variables created with valid names.
Public IP addresses
These infrastructure changes mean we can now publish IP addresses for Bitbucket Pipelines. You'll want to know these addresses if you want to whitelist Pipelines access into your AWS VPC or corporate firewall, for example.
See What are the Bitbucket Cloud IP addresses I should use to configure my corporate firewall? for the Bitbucket and Pipelines public IP addresses.
Note that our public IP addresses may change in the future.