Add service label build options

[jquick]

It would be really handy to be able to add service labels in the pipeline. This change allows labels to be defined for build or run.

This will add any defined labels to the compose override and those will be merged accordingly. Small example:

docker-compose.yml

services:
  app:
    build:
      context: .
      labels:
        - dev.pardot.docker.image-metadata=test-metadata

pipeline.yml

      - ${DOCKER_COMPOSE_PLUGIN}:
          build: app
          labels: 
            - dev.pardot.docker.test=test
            - dev.pardot.docker.test2=test2

image labels after build:

      "Labels": {
        "com.docker.compose.project": "buildkite018dd7eac0554b8eb556b2b206b874d0",
        "com.docker.compose.service": "app",
        "com.docker.compose.version": "2.12.2",
        "dev.pardot.docker.image-metadata": "test-metadata",
        "dev.pardot.docker.test": "test",
        "dev.pardot.docker.test2": "test2"
      }

Testing

I've done some basic Buldkite builds with different combinations of labels and cache_from.

Use Case

Our users setup their own compose files. As owners we want to ensure that every image is built with specific labels.

[toote]

The recommendations on shared.bash are mostly style and not functionality, but the schema one does pose a question on the implementation: if both build and run are used in a single step the labels would be the same and I don't think that is something useful. Thus, I would suggest splitting the option into two: build-labels (for build) and labels (for run).

While we are at it I would also suggest adding a test for the override function with labels, target and cache-from for completeness' sake (and I just noticed there is no test with just a target 😨)

[jquick]

Thanks @toote! I really appreciate your feedback and help. I think I have addressed the style issues and ran a few builds on the new logic and it looks to work as expected. Since we are splitting out run/build I think having build-labels and the current run-labels should be sufficient for most cases.

[toote]

👏 as long as the pipeline passes, I believe this can be merged. Thanks a lot for the work and improvement!

[pzeballos]

Thanks @jquick! We'll probably do the release at the end of the week