build-push-ecr refactor using docker/build-push-action@v3#28
build-push-ecr refactor using docker/build-push-action@v3#28thecristen wants to merge 3 commits into
build-push-ecr refactor using docker/build-push-action@v3#28Conversation
also will login if valid!
Computes needed docker image tags with metadata-action. git-$(git rev-parse --short HEAD) --> type=sha,prefix=git- (it defaults to short sha) additional tag --> type=raw,value=tag
Handles building the image pushing to ECR, enables caching
paulswartz
left a comment
There was a problem hiding this comment.
This looks good: could you do a branch on mbta/dotcom which uses it so we can make sure it works?
| aws-region: | ||
| description: AWS region to use | ||
| required: true | ||
| required: false |
There was a problem hiding this comment.
praise: 🤦 thank you for fixing this!
| with: | ||
| registry: ${{ secrets.docker-repo }} | ||
| username: ${{ secrets.aws-access-key-id }} | ||
| password: ${{ secrets.aws-secret-access-key }} |
There was a problem hiding this comment.
praise: this is neat! I didn't know the built-in action could log in directly.
| for tag in ${{ inputs.docker-additional-tags }}; do | ||
| docker tag ${{ steps.docker.outputs.tag }} ${{ inputs.docker-repo }}:$tag | ||
| docker push ${{ inputs.docker-repo }}:$tag | ||
| echo "type=raw,priority=900,value=${tag},enable=true" >> tags.txt |
There was a problem hiding this comment.
suggestion: it would be better to write this file into the $RUNNER_TEMP directory. otherwise, any existing content in a tags.txt file will be passed to the job and I don't think that's what you want.
|
One slight snag / design flaw / opportunity in this: For Dotcom we run a script against the Docker image, to extract the built assets and deploy them to S3. With the way the docker action works, we end up running |
|
@thecristen can you share an example? I would think that you could still be able to extract information from the container even after it was pushed. |
|
@paulswartz Here's an example from Dotcom, where we
But upon further reflection my example is not that great, maybe I'm overthinking it and Dotcom can instead
Will report back after trying this refactored action! |
|
GitHub Actions caching makes the Docker build process substantially faster, especially for projects like Glides that smoke test the Docker container in CI and have a lot of Elixir dependencies that change rarely but are slow to compile if not cached. Is this feature likely to land at some point, either by bringing this PR up to date or by making a new PR instead? |
|
@boringcactus if you wanted to take on that work, please feel free! |
This PR tries out rewriting our
build-push-ecrworkflow to use Docker's actions. Dotcom is using a variation on this in its deployment workflows and it seems to be working okay!This enables caching. The build-push-action and has many more interesting configuration options that we might want to support, and the metadata-action has more granular tagging abilities; but in this PR I mainly focused on a 1:1 match with our current action's features.