Push builds images without respecting the `args` argument

[patrobinson]

Push builds an image without respecting args argument If you specify build and push at the same time, the image will be built twice The resulting image built without args argument will be pushed

So if you configure the plugin like so:

- docker-compose#v3.5.0:
          build: web
          args:
            - NODE_ENV=staging
            - RACK_ENV=staging
          push: foo:bar

1. args has no effect
2. your build takes twice as long because it gets built twice

This way works:

- docker-compose#v3.5.0:
          build: web
          args:
            - NODE_ENV=staging
            - RACK_ENV=staging
          image-repository: foo
          image-name: bar

https://github.com/buildkite-plugins/docker-compose-buildkite-plugin/blob/master/commands/push.sh#L41 should probably call the same code path that build uses, allowing it respect all arguments build supports.

[toote]

This indeed looks like a bug or, at least, very poor documentation

[toote]

@patrobinson, first and foremost sorry for the delay in getting back to you. Hope that you have continued to use the plugin since and found the improvements and fixes made since you reported the issue helpful.

I believe I have finally figured out what was wrong with this scenario (in addition to the push portion of the code not respecting the same logic as the build one). To start with, mixing build and push was not officially supported until version 3.12. But most importantly, your push configuration states foo:bar which means service foo to be pushed to repository/tag bar. The matter should have been solved by changing that option to web:foo:bar. That is indeed part of the documentation examples from even before this ticket was opened and - from what I understand of the code - the build portion of the could should have even printed a warning stating that the image wouldn't have been pushed because of missing configuration variables. The rest of the behaviour is extremely dependent on your docker-compose.yml file.

As mentioned in #325 the implications of allowing multiple "stages" to be used in the same step would have unintended consequences and this one appears to be one of them. A double-build is definitely not a desired behaviour, but shouldn't delay the step too much thanks to docker's layer cache (so the second build should basically be a no-op).

If you have more information about this particular scenario we will be more than happy to continue to troubleshoot and/or get ideas for future improvements of this plugin :)