drone-runtime icon indicating copy to clipboard operation
drone-runtime copied to clipboard

driver: compose

Open bradrydzewski opened this issue 6 years ago • 2 comments

I've been trying to figure out what a docker-compose runner might look like. So many people try to run docker-compose inside drone using docker-in-docker or mounting the host machine socket and it is always a mess. It would be great to have a runner that natively supports these types of workflows.

I just started jotting some ideas down for what this could look like:

kind: pipeline
type: docker-compose

up:
- docker-compose.yml
- docker-compose-e2e.yml

exec:
- foo ./test_runner_script.sh
- bar ./test_runner_script.sh

push:
- foo/bar

config:
  auths:
    docker.io:
      username: foo
      password: bar

Some outstanding questions:

  • syntax to enable docker push on pull request?
  • syntax to skip commands based on branch, event, etc (similar to when)
  • should this runner support Drone plugins? If so what does that look like?
  • we still need some magic to build images using a unique identifier and then push images using the user-defined name

related articles:

  • https://blog.pusher.com/full-stack-testing-docker-compose/
  • https://rancher.com/docker-based-build-pipelines-part-1-continuous-integration-and-testing/

bradrydzewski avatar Jul 27 '19 15:07 bradrydzewski

  1. you want to be able to inject env variables
  2. some kind of pre script also makes sense for preparing the stack requirements
  3. use by default an array similar to conditions, but optionally allow an object for conditions and things like that

These are my 2 cents

tboerger avatar Jul 27 '19 15:07 tboerger

@tboerger would love to see a mockup of how you think the yaml could look :) I know you use compose for testing so you probably have better ideas than I do.

bradrydzewski avatar Jul 27 '19 18:07 bradrydzewski