use GitHub Actions to build Docker container

[cardoe]

Start using GitHub Actions to build the Docker container for this
project. Builds all tags and master as the latest container tag. Builds
for amd64 and arm64.

[cardoe]

This will require you to to add two secrets DOCKERHUB_USERNAME and DOCKERHUB_TOKEN under Settings -> Secrets -> Environment Secrets. The later is expected to be a Docker Hub Personal Access Token. See https://github.com/docker/login-action#docker-hub for more information as this is the action that is used.

The reason for this PR is that the project current uses Docker Hub's Automated Build to generate the containers however per https://www.docker.com/blog/changes-to-docker-hub-autobuilds/ they have disabled auto builds by default unless the project signs up as an official Open Source project, which this project hasn't done. Additionally the Automated Build environment is a bit limited for things like multi-platform builds (which this PR uses) and lots of folks have started to switch to GitHub Actions for container building.

[cardoe]

Note: This PR will fail until the author sets up the Secrets appropriately.

[cardoe]

fixes #1126 fixes #1140

[mher]

@cardoe login action is failing despite adding DOCKERHUB_USERNAME and DOCKERHUB_TOKEN

[cardoe]

Indeed. I'm guessing its failing to auth because its saying Error: Username and password required

[cardoe]

https://github.com/docker/login-action#docker-hub are the docs for the action. It appears they've moved to v2 so we can try going to v2, otherwise I can only guess its a creds issue.

[cardoe]

Functionally there's no difference between v1 and v2. v2 just requires a newer GitHub Actions Runner version so they treated that a semver change. Only guess is its a cred issue. You made a Personal Access Token https://docs.docker.com/docker-hub/access-tokens/ that had permissions to push to mher/flower?

[scottd018]

@cardoe @mher Looks like this may be a problem with a forked repo:

docker/login-action#29 (comment)

I believe the workflow may want to be switched to:

on:
  push:
    branches:
      - master
    tags:
      - '*'

Which would (theoretically, untested) only publish a new image on a new pushed tag to the master branch. No new images would be generated on PRs (from forks).

Thoughts on this approach? I can submit a PR if that sounds good.

[scottd018]

Also, @mher is there a chance you can push a new image for version v1.1.0 to the mher Docker Hub repo when you get a chance? This would unblock me from using flower for my application. Right now, the latest one in Docker Hub has several vulnerabilities which won't allow me to use it. I have built and scanned off of master and it looks good. The challenge being that I don't want to push and maintain the forked copy (because we all know how that goes...ha).

Apologies for this one-off request, as we have some tight security controls that I'm working around. Much appreciated for being responsive on this one!

[cardoe]

@cardoe @mher Looks like this may be a problem with a forked repo:

docker/login-action#29 (comment)

I believe the workflow may want to be switched to:

on:
  push:
    branches:
      - master
    tags:
      - '*'

Which would (theoretically, untested) only publish a new image on a new pushed tag to the master branch. No new images would be generated on PRs (from forks).

Thoughts on this approach? I can submit a PR if that sounds good.

I don't believe you are correct. Those triggers are already done. We additionally include PRs so that we attempt to build the Docker container on PRs. If you look at the login action

flower/.github/workflows/docker.yml

Line 34 in d91fbbf

if: github.event_name != 'pull_request'

it explicitly skips for PRs. The failed run didn't happen on the PR, the failed run happened in master. You can even see the follow on PR built here https://github.com/mher/flower/actions/runs/2634395754 successfully.

[mher]

Functionally there's no difference between v1 and v2. v2 just requires a newer GitHub Actions Runner version so they treated that a semver change. Only guess is its a cred issue. You made a Personal Access Token https://docs.docker.com/docker-hub/access-tokens/ that had permissions to push to mher/flower?

@cardoe yes, the token has Read, Write, Delete scope. I'm able to docker login from the command line using the same credentials.

[mher]

Moving secrets from Environment secretsto Repository secrets solved the issue

[scottd018]

I don't believe you are correct. Those triggers are already done. We additionally include PRs so that we attempt to build the Docker container on PRs. If you look at the login action

flower/.github/workflows/docker.yml

Line 34 in d91fbbf

if: github.event_name != 'pull_request'

it explicitly skips for PRs. The failed run didn't happen on the PR, the failed run happened in master. You can even see the follow on PR built here https://github.com/mher/flower/actions/runs/2634395754 successfully.

Ah, yeah, my bad. Looked at that wrong.

Regardless, looks like you have it solved and working. I see the master tag in DockerHub now, so I can use that one until a tagged release is present. Thanks again @mher and @cardoe !

[cardoe]

Awesome. Thanks for the follow up @mher didn’t even think about the difference between the two. I’ll make a follow up PR to have master go to latest.

Edit: What was I thinking about master to latest. latest is for the newest release and the code will work right. Next tag everything will be all updated.