Add build flag similar to push flag

[garethr]

At present it's possible to set push to false and just build an image. This is useful when you want to test the image before pushing it. But when you do that, pushing becomes either a matter of doing so manually (potentially with multiple tags), or triggering the full action again, including a build.

It would be useful to run just the push action, maybe by adding a property for build that defaults to true?

[zappy-shu]

Thanks for your feedback @garethr. I've put this suggestion onto the backlog and will discuss it with our PM 👍

[Jtalk]

Implementing this one would help a lot with third party building tools, e.g. sbt's docker:publishLocal. Having your images built automatically by sbt while benefitting from a uniform tagging approach provided by this action would certainly bring it to the next level.

Perhaps a pair of separate actions for Docker push & Docker build?

[shankari]

@zappy-shu I was planning to volunteer to submit a PR for this, but I am not sure where the source code is. It looks like it uses the https://hub.docker.com/r/docker/github-actions container, but I don't see a dockerfile or source repo for it.

Please tell me that the default github actions are not closed source!

If you have a repo where the code is, I am happy to submit a PR.

[zappy-shu]

@shankari the whole of docker's github action is open-source with the backend image being built from https://github.com/docker/github-actions. It's been separated for a few reasons, the main one being in case we wish to use the image as a backend for other actions. Please feel free to open a PR if you wish to contribute.

One of the big questions is how to deal with tags. The current flow of this action builds the image with all the tags defined in tags, tag_with_sha, and tag_with_ref depending on what the user sets the values to and then pushes all of them. With this the original image will have already been built and tagged by a previous step so we need to consider:

• How to get the image's current tag?
• What tags to tag the image with (this will most likely require retagging the image)?
• What tags to push?

One thing I think is essential is for the action to output what tags it builds and/or pushes with as per #24. Most likely 2 outputs:

• A version-tags output that is just the end of the tag (e.g. v1,v1.0.1)
• A fully-qualified-tags output that has the whole tag (e.g. myreg/myorg/myrepo:v1,myreg/myorg/myrepo:v1.0.1)

A simple way to deal with it is to not bother with retagging and just try and push all the tags given. E.g.

# Builds the image and tags it as myorg/myrepo:foo and myorg/myrepo:{ref}
- name: build
  id: build
  uses: docker/build-push-action@v1
  with:
    repository: myorg/myrepo
    tags: foo
    tag_with_ref: true
    push: false

### Do other stuff

# Pushes the image with tags myorg/myrepo:foo and myorg/myrepo:{ref}
- name: push
  uses: docker/build-push-action@v1
  with:
    build: false
    username: ${{ secrets.DOCKER_USERNAME }}
    password: ${{ secrets.DOCKER_PASSWORD }}
    repository: myorg/myrepo
    tags: ${{ steps.build.outputs.version_tags }}

This is relatively simple but doesn't allow retagging between the build and push. Another option is to have some sort of "original image" input that is used simply to find the initial image in the push step which is then retagged and pushed with the new tags. E.g.

# Builds the image and tags it as myorg/myrepo:foo
- name: build
  id: build
  uses: docker/build-push-action@v1
  with:
    repository: myorg/myrepo
    tags: foo
    tag_with_ref: true
    push: false

### Do other stuff

# Pushes the image with tags myorg/myrepo:{ref}
- name: push
  uses: docker/build-push-action@v1
  with:
    username: ${{ secrets.DOCKER_USERNAME }}
    password: ${{ secrets.DOCKER_PASSWORD }}
    repository: myorg/myrepo
    original_image: ${{ steps.build.outputs.full_tags }}
    tag_with_ref: true

As an aside, because of build caching, rebuilding the image shouldn't actually cost that much time unless the steps between the initial build and the build-push break the cache somehow (modifying files or the like).

@nebuk89 any thoughts?

@garethr it'd be great to have your opinion on how you envisage the flow working as well

[khitrenovich]

The main drawback of rebuilding the image is that is breaks "build-test-promote" concept. In other words, you want to test what you've built before pushing and want to push exactly the image you tested.

[zappy-shu]

@khitrenovich agreed. It's not ideal so was just a side note for those only worried about CI/CD time

[nebuk89]

We are still considering whether to do a separate build action or just have a build flag in this action (we will start the 'doing' very soon either way!) What do people prefer? 🤔
👍 for flag
🎉 for separate action

[garethr]

@zappy-shu I like the explicit nature of tags: ${{ steps.build.outputs.tags }}.

I think it's worth considering the various compositions here as well. ie.

1. Only build
2. Only push
3. Build and push

This raises the question of, can you benefit from things like tag_with_ref if you're only pushing, or only building? If the answer is no, then to @nebuk89 point, maybe overloading the action isn't the way to go.

[shankari]

This is relatively simple but doesn't allow retagging between the build and push. Another option is to have some sort of "original image" input that is used simply to find the initial image in the push step which is then retagged and pushed with the new tags. E.g.

When I volunteered to write the PR, I was planning to have an "original image" output from the build step that would be something like <name>:<sha> and then allow the user to specify additional tags as part of the push step.

[shankari]

We are still considering whether to do a separate build action or just have a build flag in this action (we will start the 'doing' very soon either way!) What do people prefer? 🤔

Will the "separate action" also have support for multiple repositories (e.g. dockerhub, github packages, etc)?

[Jtalk]

Should we just provide 3 separate actions (push, build, build&push) based on the same underlying docker container (i.e. https://github.com/docker/github-actions)? I doubt it introducing a new input would do any good.

[emersonreisdev]

I think having a new input is the way to go, it follows the same principles outlined here https://www.docker.com/blog/first-docker-github-action-is-here/

I do not have anything to add other than what they already said in the article.

[sualeh]

@nebuk89 - do you have a timeline for resolution of this issue?

[ppmathis]

To add my two cents here, I'd definitely appreciate the option of specifying an original image, which then gets tagged according to the input parameters (e.g. static tags, tag by ref, tag by SHA, ...) and pushed to the repository. I think this is pretty much the second way which @zappy-shu proposed.

This would allow me to build the image myself in an earlier step with an action of my choice (e.g. whoan/docker-build-with-cache-action to save some time and resources) and then still make use of the automated tagging and pushing which this action provides. Currently there is no easy way to do so, especially when leveraging multi-stage builds as they'd require specifying explicit cache-from directives.