Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Pipelines won't mount volume under $BITBUCKET_CLONE_DIR

Dominik Jarco
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
May 18, 2020

I'm trying to mount some volumes in my pipeline as part of docker-compose up. I was originally using $PWD to mount volumes relative to the directory the docker-compose files were in, but I keep running into the following error:

ERROR: for db Cannot create container for service db: authorization denied by plugin pipelines: -v only supports $BITBUCKET_CLONE_DIR and its subdirectories

This occurs even after changing the volume to be explicitly underneath the directory bitbucket is cloning into. I've run echo $PWD in the pipeline to see that it's building in

+ echo $PWD
/opt/atlassian/pipelines/agent/build

But even after explicitly setting my volume underneath this directory, I still get the above error.

Here's the relevant section of my docker-compose:

version: '3'

services:
db:
image: mongo:latest
container_name: db
ports: - "27017:27017"
volumes: - db-data:/data/db 

volumes:
db-data:
driver: local
driver_opts:
type: none
device: /opt/atlassian/pipelines/agent/build/server/db
o: bind

 The only other thing that could be relevant is that the server dir is a submodule, but I'm cloning it successfully because it's running the docker-compose file and doing an ls in the pipeline reveals that all the files and folders are there.

 

Any help on this would be great, I've been stumped on this for a whole day.

1 answer

1 accepted

0 votes
Answer accepted
Dominik Jarco
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
May 19, 2020

I figured out that the issue was mounting a named volume. Ie if I did:

volumes: 
- ${PWD}/db
:/data/db 

Instead of declaring the volume at the bottom of the compose file and referring to it by name, it worked. This seems like a bug in Pipelines.

The other issue I came across next was it complaining when trying to run the db:

db           | chown: changing ownership of '/data/db': Operation not permitted
db | chown: changing ownership of '/data/db/.gitignore': Operation not permitted 

Turns out the default entrypoint for the mongodb docker image ("docker-entrypoint.sh mongod") was trying to perform chown operations which were unnecessary, but which Pipelines for some reason forbids. Changing the entrypoint of the db service to:

entrypoint: mongod --bind_ip_all

solved the issue, and the database now starts up correctly. Without --bind-ip-all, mongod just starts the database locally, so it isn't accessible from other containers. It seems this is something the docker-entrypoint.sh script provided by the mongodb image takes care of, so if you're not using that script you have to do it yourself.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events