seek-oss/docker-ecr-publish-buildkite-plugin

Build, tag, and push Docker images to Amazon ECR

docker-ecr-publish-buildkite-plugin's Issues

How to download artifacts from previous steps pre docker build.

I'd like to download build artefacts from previous steps so that they are available to the docker build command.

We have a vanilla build pipeline

• build, test, package, upload packaged artefact
• docker build (with ADD ./artefact) & publish to ECR

I cant find a hook point to add buildkite-agent artifact download ...
Is this possible at the moment?

Add region support

It would be great if I could specify the region the ECR is located in, Our build setup has all of our builds running in US-WEST-2 but yet our ECR is located in US-EAST-1

Add additional_build_args to docker build command

In the docker build line https://github.com/seek-oss/docker-ecr-publish-buildkite-plugin/blob/master/hooks/command#L131

It would be very useful to copy the great idea used in the cache plugin to specify additional arguments to docker build, see https://github.com/seek-oss/docker-ecr-cache-buildkite-plugin/blob/master/hooks/pre-command#L196

The main use case is passing --progress=plain for setting DOCKER_BUILDKIT=1 (see https://docs.docker.com/develop/develop-images/build_enhancements/#new-docker-build-command-line-build-output)

How to set region of ECR repo?

We have ECR repositories in multiple regions — how can we configure this plugin so that it pushes to a given region?

Seeing as this plugin uses aws cli, I figured that we may be able to configure it as follows:

- branches: stable
    label: ":ecr: Stable image (me-south-1)"
    env:
      AWS_DEFAULT_REGION: me-south-1
    plugins:
      - seek-oss/docker-ecr-publish#v1.2.0:
          ecr-name: calibre/reporter
          tags:
            - stable

This returns an error, stating: An error occurred (RepositoryNotFoundException) when calling the DescribeRepositories operation: The repository with name 'calibre/reporter' does not exist in the registry with id '<account id removed from paste>

.

latest tag being added on master branch causes issues when ECR has tag immutability turned on

Hi,

I would like to be able to configure the behaviour of adding the 'latest' tag to images if on the master branch. Our ECR repos do not allow tags to be mutable (Tag immutability toggle is turned off) and hence using the latest tags is causing us issue.'

Thanks!

Race condition on concurrent builds

We encountered a race condition when running two buildkite agents on the same host.

We had two builds, build A and build B running concurrently:

• Build A completed building the image and tagging it with {ecr_name}, as no version was specified it defaulted to latest.
• Build A then initiated a remote call to the AWS ECR API.
• Meanwhile build B completes building it's image and also tags it with {ecr_name}:latest
• When both builds A and B come to setting the remote tags, they are now both using the image created by build B

I've raised a pull request with a suggested fix #33

@72636c

Error using save-digest-as-metadata

Error message:

--- Saving Docker image digest to Buildkite metadata: my-metadata-variable

/var/lib/buildkite-agent/plugins/github-com-seek-oss-docker-ecr-publish-buildkite-plugin-v2-4-0/hooks/command: line 229: image: unbound variable

�[31m🚨 Error: The command exited with status 1�[0m
^^^ +++
^^^ +++
user command error: The plugin docker-ecr-publish command hook exited with status 1
~~~ Running global pre-exit hook
�[90m$�[0m /etc/buildkite-agent/hooks/pre-exit
~~~ Stopping ssh-agent 15751

Basic pipeline

steps:
  - plugins:
      - seek-oss/docker-ecr-publish#v2.5.0:
          ecr-name: e2e-smoke-tests
          save-digest-as-metadata: my-metadata-variable

@72636c

Allow default "latest" tag to be skipped

If an ECR repository is configured with immutable tags, this plugin will fail when it tries to push the latest tag.

Are you open to making that default tag optional so it can be skipped for immutable repositories?

v1.3.0 "target" parameter defaults to "."

It appears there's a mistake for the target parameter introduced in #16 which appears to default the target parameter to a dot ("."). This conflicts with build context and probably should be blank. Specifically this line should not have the final dot inside the curly braces.

This blocks #17 not to mention might cause errors for people using v1.3.0.