Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Source directory not auto-created with docker-compose v2.29.3 volumes in Bitbucket Pipelines #12140

Closed
iamvinov-atlassian opened this issue Sep 20, 2024 · 1 comment

Comments

@iamvinov-atlassian
Copy link

iamvinov-atlassian commented Sep 20, 2024

Description

When using volumes to bind mount non-existing source directories, the directories are not automatically created in docker-compose v2.29.3 in Bitbucket Pipelines. According to the docker volumes documentation, when using the --volumes flag, the directories should be created (I can confirm this was the case with the v2.29.2). Though the documentation is about Docker CLI, I imagine this behaviour should extend to docker-compose files since, as mentioned before, this was the behaviour with v2.29.2.

Steps To Reproduce

Consider this docker-compose file:

services:
  localstack:
    image: alpine
    command: [ "echo", "hi" ]
    ports:
      - "4566"
    volumes:
      - "./to-be-created-directory:/dot"

This bitbucket.yml file:

pipelines:
  default:
    - step:
        name: Bind mount test
        services:
          - docker
        script:
          - echo "Installing Docker Compose v2"
          - source ./bin/install-docker-compose-v2.sh
          - docker info
          - docker compose version
          - docker compose up

The error you get will be:

Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /opt/atlassian/pipelines/agent/build/to-be-created-directory

Compose Version

Docker Compose version v2.29.3

Docker Environment

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  compose: Docker Compose (Docker Inc., v2.29.3)
Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 0
 Server Version: 25.0.3
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7c3aca7a610df76212171d200ca3811ff6096eb8
 runc version: v1.1.12-0-g51d5e94
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
 Kernel Version: 6.1.79
 Operating System: Alpine Linux v3.19 (containerized)
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 5.953GiB
 Name: 546c8a24-f89c-4701-a5ae-98ba9623e73a-6wzx7
 ID: 80fc7e11-08f7-4573-bdf7-a147ba9bf677
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  10.28.221.186:5000
  127.0.0.0/8
 Registry Mirrors:
  http://10.28.221.186:5000/
 Live Restore Enabled: false
 Product License: Community Engine

Anything else?

Also note that I only notice this behaviour in Bitbucket Pipelines. I am not able to reproduce this issue when running docker-compose locally on a Ubuntu system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants