Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Pipelines Build Setup taking too long


I've been playing around with pipelines and have managed to get my pipeline working exactly the way I want. However it takes 5 minutes to run and looking back through the logs most of this is due to the Build Setup portion of each step.

My pipeline has 3 steps and the Build Setup takes between 30s and 90s on each step. 

I was using a private docker image but have changed this to be a public image as I understand these are cached however this hasn't affected performance.  The image is large (650MB). The repo is about 25mb.

Any ideas of what I can change to improve / diagnose the performance issues?



name: pjcable/temp:meteor-base-v3
#username: pjcable

max-time: 5


- step:
name: Testing
max-time: 3
- composer
- cp .env.example .env
- composer install
- php artisan key:generate
- sleep 10
- vendor/bin/phpunit
- php artisan serve &
- php artisan dusk
- kill $(jobs -p)
- mysql
- dusk-runner

- step:
name: Generate production assets
- node
- echo "<?php return [ 'number' => ${BITBUCKET_BUILD_NUMBER}];" > config/version.php
- npm install
- npm run production
- git config --global "Meteor Bot"
- git config --global ""
- git commit -am "Committing V${BITBUCKET_BUILD_NUMBER} production assets"
- git remote remove origin
- git remote add origin https://${BB_AUTH_STRING}
- git push origin "V${BITBUCKET_BUILD_NUMBER}"
- step:
name: Deploy to staging
deployment: staging
#trigger: manual
- echo "Push to staging server"
- ssh -v "echo hello"
- envoy run deploy-staging --verbose --release_tag=V${BITBUCKET_BUILD_NUMBER}

image: mysql:5.7
MYSQL_DATABASE: 'homestead'
MYSQL_USER: 'homestead'
image: pjcable/dusk-runner:latest



20 answers

Hello, how can this be neglected for so long? This is a crucial bottleneck in effectively using Bitbucket Pipelines. We are losing minutes every day and therefore hours every month because of this. Please give this ticket the attention it deserves?

7 votes
Deleted user Aug 01, 2018

We have the same issue. Pipeline's build setup speed varies from 30 seconds to 50 minutes!

This is the output of the build setup and unfortunately there is no timing being printed out in details except the time took for downloading caches. However, the whole step took 46 minutes:


+ umask 000+ GIT_LFS_SKIP_SMUDGE=1 git clone --branch="CT-123-change-parameter-name-in-entity" --depth 50 https://x-token-auth:$ $BUILD_DIR ; git reset --hard 8bdfe2cf4dd33902b321208d92a90f8f236d3660 ; git remote set-url origin
Cloning into '/opt/atlassian/pipelines/agent/build'...
HEAD is now at 8bdfe2cf4 CT-123: issue description
+ chmod 777 $BUILD_DIR
Cache "maven": Downloading
Cache "maven": Downloaded 226 MB in 14 seconds
Cache "maven": Extracting
Cache "maven": Extracted in 3 seconds
Cache "nodemodules": Downloading
Cache "nodemodules": Downloaded 4 MB in 1 seconds
Cache "nodemodules": Extracting
Cache "nodemodules": Extracted in 0 seconds

this not only costs us but also delays the development team. Any idea?



Any update on this question?  

I'm raising a task.

It's extremely frustrating that we're being BILLED per minute that we have to wait on bitbucket to setup its own infrastructure.

Sometimes a step for me takes 15 minutes to "Setup" but only 1 minute to run. It feels extremely unjust to charge us for Atlassians own serverless issues. It can't be something we've done, as often that setup step will be instant.

We're using the Atlassian firebase deploy pipe for reference.

Our company already moved away from JIRA to another project management platform because it was just consistently extremely slow. It's looking more like we'll need to migrate off bitbucket too, given how slow merging branches and running pipelines has become in the last months. (Across more than 3 medium sized projects on different tech stacks).

It'd be nice if performance was a bigger priority at Atlassian.

I have the same issue. We are a paid customer and sometimes the Build setup step at the very beginning takes 2+ minutes.

Yes, this issue is starting to become fairly frustrating for me also.

Realy Attlassian? reply, no help...nice support!

I agree - my most recent pipeline was 4min & 41 seconds of which <50 seconds were tests that I want to run.

If i'm going to be continually billed for ~5x the amount of machine time I'm using, I'll just solve this problem with a githook and a bash script.

The variable time for build setup is ridiculous - sometimes it's 10 seconds, other times it's 10 minutes.

If I hadn't have already clocked over 50 build minutes and been charged overages I'd already be turning it off.

I know that the underlying architecture of pipelines is serverless, which makes me wonder if that's not the source of the slowness and variability...

I was able to save few seconds by setting artifacts download to false to all steps where artifacts are not needed

- step: &set-build-env-step

name: 'Set build env'


- yarn


download: false


- '.env'

Do you know if the selfhosted runners are faster?

I would actually prefer to pay for a small VM to do all my jobs!

I noticed that every Build setup stage of every step in pipeline takes a lot of time. So, when I combine all my 3 steps into one with flat script inside, total time of deployment reduced 3 times too.
But still, "Build setup" stage takes half of time of the whole process.

3 years and not even a single reply...?

Same problem here... this definitely needs to be addressed.

Thank Atlassian, I am sitting right now in front of the laptop waiting for the pipeline and now the berlin time is nearly 20:00 in the evening. U can do nothing but wasting time 🤢

using default image 2, same issue

Any update?

We encounter same issue. Performance is really unstable - same pipeline might take 5 minutes in one run or 1 hour in another. Making me think if this was the right tool to use. 

We have the same issue. Steps are nice thing and it's probably useful in some cases that each step is a new docker image, but in our (and perhaps most?) use cases there is really no benefit and waiting 30s each step is not optimal.

0 votes
Danyal Iqbal
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Aug 01, 2018 • edited

Conventional wisdom would provide resources to the environment. However, docker builds are conventionally slow. (Docker is not the rockstar, everyone thinks it is:)

You can optimize the build time using the --cache-from feature, see an example:

- step:
- docker
- export IMAGE_NAME=your-docker-hub/your-repo:$BITBUCKET_BRANCH
- docker login --username $DOCKER_HUB_USERNAME --password $DOCKER_HUB_PASSWORD
- docker pull $IMAGE_NAME || true
- docker build --cache-from $IMAGE_NAME -t $IMAGE_NAME .
- docker push $IMAGE_NAME

Avoid using the pipeline docker cache, only wastes time... :)

check for more infos.

Thanks Danyal however this doesn't address the issue i'm looking at.

The setup you show and the docker cache only apply to when you're building docker images within your pipeline.

The image that takes forever to load for me is actually the custom build agent image. 

Like # people like this

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events