docker-compose-buildkite-plugin
docker-compose-buildkite-plugin copied to clipboard
Branch names with "/" fail when used in Docker tags
A common workflow of using cache-from
is to include the branch name, via ${BUILDKITE_BRANCH}
, in the Docker tag. But if someone pushes a branch with a /
character in it (e.g. Dependabot's default behaviour), it will create an invalid tag and the push will fail.
For example:
steps:
- plugins:
- docker-compose#3.2.0:
build: app
cache-from:
- app:index.docker.io/my-org/my-repo:${BUILDKITE_BRANCH}
- app:index.docker.io/my-org/my-repo:master
push:
- app:index.docker.io/my-org/my-repo:${BUILDKITE_BRANCH}
There's no alternative pipeline.yml syntax for stripping or replacing the /
in the environment interpolation, so our best bet is probably to do our own cleanup of the tag names, based on anything after the :
character?
I created an agent hook for environment
that sets BUILDKITE_BRANCH_SLUG
:
#!/bin/bash
set -euo pipefail
echo '--- :house_with_garden: Setting BUILDKITE_BRANCH_SLUG'
export BUILDKITE_BRANCH_SLUG=$(echo $BUILDKITE_BRANCH | sed 's|/|--|g')
I then use that for my image tags
I'm doing the same as @tjwallace here :)
It seems like this is something that 99% of people using this plugin for caching would want to use... Should the readme be updated with an example?
No idea why but I had to move the export BUILDKITE_BRANCH_SLUG
assignment out of .buildkite/hooks/environment
and into .buildkite/hooks/post-checkout
, otherwise the ecr cache was using :latest
tag again
Enabling DOCKER_BUILDKIT also may not work well with caching in my experience.
The hack posted by @tjwallace got me unstuck. Is this (e.g., a Docker-tag-safe version of the Git branch name) something the buildkite-agent
should always expose? I have these sorts of hacks (or another version, echo $BRANCH | tr '/' '-'
) littered throughout our codebases.
I have created PR #345 to validate tags... unfortunately there is no way to correct them on the fly as the BUILDKITE_BRANCH
variable is not supposed to be changed nor would we want to modify user-supplied configuration just like that.
What I've done instead is validate the values and just skip those (in cache-from
and push
options) that don't have valid tags. That way you can have a generic pipeline and those values that are valid will still work.