Composite Docker action

Hi guys,

this is not really an issue, but some feedback that you hopefully consider: I’m aware I probably sound like a whiny crybaby, but please believe me that I admire your efforts… but seriously: with v2 you raped a good working Github action.

And yes yes, you’re probably thinking: Why don’t you fix it then yourself? But I’m already managing two dozen repositories for the FAForever project and I just need an easy and working CI infrastructure. [And v1 is still available, so technically no problem.]

Why do I use this action? I prefer Github actions because they are easier to read and simplified building blocks over writing it in a shell script, even if they are a few (!) lines longer

And v1 of this action is the perfect solution for the workflow I need (with some Github if expression magic):

      - name: Build and push Docker images
        if: github.ref == 'refs/heads/develop' || startsWith(github.ref, 'refs/tags')
        uses: docker/build-push-action@v1.1.1
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}
          repository: myproject/myrepo
          tag_with_ref: true

What has changed? With v2 I need to split it off in 3 steps (+ an additional one considering #100):

• one step declaring the tag I want to push
• one step for a login (yes, if I want to push I ALWAYS want to login)
• one step for the build & push

Eventually I end up with 3x the lines of code that I had before. No thanks, I rather stick with the previous version or go back to manual shell commands.

Here are some ideas to improve on v2:

• I do understand that it makes sense to have a login action if you want to pull images from a protected repository. But why does this have to affect the build-and-push step? If already logged in for other reason, this is the special case not the default, so my proposal would be to either ignore this case (double login then) or to offer an login opt-out config flag instead.
• I do understand that the tag_with_ref flag was quirky and limits some scenarios like pushing multiple tags and I actually like that there is another way now to configure this now. But was it necessary to drop the existing flag? Maybe you can consider bringing it back under a more meaningful name.
• Looking at the upgrade guide it seems that context and file are mandatory now (didn’t test it actually) but then again: why would I need to declare what is the 99% default case? So if it’s not mandatory I’d to remove it from the upgrade document, and if it is mandatory I’d suggest to offer default settings for a classic Dockerfile build

I’d love to see a very powerful action as it is now, with sensible default settings preconfigured for the simple use cases.

Love you guys! Keep up the good work! ❤️

[worldofgeese]

I’m currently working on an action called Docker meta allowing a management of tags and labels similar to the old flags used in v1. #206 was created to integrate this action as an example.

But this is one of the many issues with v2: you keep making new actions (more complexity) when what users want is something simple out-of-the-box with optional complexity. And even those options should be presented simply.

As an example: why am I leveraging multiple caches with opaque language? It’s starting to look like a DSL. A key-value of cache: yes should be all that is needed. This

          cache-from: type=registry,ref=user/app:latest
          cache-to: type=inline

and

          cache-from: type=local,src=/tmp/.buildx-cache
          cache-to: type=local,dest=/tmp/.buildx-cache

mean nothing to the uninitiated. If that is the language used behind the scenes, don’t present that to the user!

You’ve taken something that needed a few tweaks and turned it into something for people to spend hours pouring over documentation for the right recipe of incantations that result in a successful build.

[alerque]

@CrazyMax I’ll look forward to a v3 of this action (or a new one entirely) that works like that and brings some sanity to simpler projects. For now v1 still functions nicely. 😉