Setup GitHub Actions for automated multi-arch container build and push to dockerhub

[just5ky]

You can use GitHub actions to build multi-arch images
https://github.com/marketplace/actions/docker-setup-buildx

Found a tutorial on how to do it.
https://youtu.be/cXagGh_7TH4

I mixed both together and made this on another repo
https://github.com/Just5KY/scalyr-tool/blob/main/.github/workflows/dockerhub.yml

I can create a PR if you want

[xavier-hernandez]

@just5ky I was actually looking at github actions recently but didn't really have time. I was looking at something created by crazy-max but yours looks super easier. Feel free to create a PR. Once you complete your PR I'll try it out on a different repo of mine and make sure everything works then I'll approve it. Don't want to accidentally mess up the images :P

What does this do, schedule an auto build?
schedule:
- cron: '50 15 * * *'

[just5ky]

on:
  schedule:
    - cron: '50 15 * * *'      #Build image when dailt at 15:50 but im not sure which timezone.
  push:
    branches: [ main ]        #Build image when there is a comitt push
    # Publish semver tags as releases.
    tags: [ 'v*.*.*' ]
  pull_request:
    branches: [ main ]       #Build image after a pull request is accepted
  workflow_dispatch:       #Adds a button to manually build image in GitHub actions page.

You can use https://crontab.guru/ to make a cron schedule

I am still playing around with it, but it works

[just5ky]

I also found this
https://github.com/Yooooomi/your_spotify/blob/master/.github/workflows/client.yml

Its clear implementation, but it does not have automatic builds

[just5ky]

You can just add this to your test repo like test_repo/.github/workflows/FILENAME.yml

you need to create a GitHub secret for your docker hub access token with the name DOCKERHUB_TOKEN

name: Docker multi-arch build and push

on:
  schedule:
    - cron: '50 15 * * *'
  push:
    branches: [ main ]
    tags: [ 'v*.*.*' ]
  pull_request:
    branches: [ main ]
  workflow_dispatch:

env:
  REGISTRY: docker.io
  IMAGE_NAME: test_image_name

jobs:
  build:

    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      # This is used to complete the identity challenge
      # with sigstore/fulcio when running outside of PRs.
      id-token: write

    steps:
      - name: Checkout repository
        uses: actions/checkout@v2

      # https://github.com/docker/setup-qemu-action
      - name: Set up QEMU
        uses: docker/setup-qemu-action@v1

      - name: Setup Docker buildx
        uses: docker/setup-buildx-action@79abd3f86f79a9d68a23c75a09a9a85889262adf

      - name: Login to Docker Hub
        uses: docker/login-action@v1
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}
        
      - name: Build the Docker image
        run: docker buildx build --push --platform linux/amd64,linux/arm/v6,linux/arm/v7,linux/arm64/v8  --tag ${{ secrets.DOCKERHUB_USERNAME }}/test_image_name .

[xavier-hernandez]

@just5ky @martadinata666

@just5ky I committed your PR then I made some modifications that I was talking about previously. I also added some additional steps. Not sure if everything is as simple as it should be but have a look at the workflow. Can you test the new develop image and latest image on your local, before I update the README file?

• changed the auto-build for tags only
• will run the workflow manually for main and develop branch, until I get a better handle on mods that I make
• main branch - docker image will be flagged as "latest"
• tags - docker image will be flagged with the tag, i.e. "v1.0.5"
• develop branch - docker image will be flagged as "develop"

[xavier-hernandez]

@just5ky @martadinata666 - thanks for all your help on getting this done. Saved me a bunch of time.

[just5ky]

@xavier-hernandez i tested both Latest and Dev image, works just fine.

[martadinata666]

@just5ky @martadinata666

@just5ky I committed your PR then I made some modifications that I was talking about previously. I also added some additional steps. Not sure if everything is as simple as it should be but have a look at the workflow. Can you test the new develop image and latest image on your local, before I update the README file?

* changed the auto-build for tags only

* will run the workflow manually for main and develop branch, until I get a better handle on mods that I make

* main branch - docker image will be flagged as "latest"

* tags - docker image will be flagged with the tag, i.e. "v1.0.5"

* develop branch - docker image will be flagged as "develop"

As workflows itself depends on personal preferences, from your need stated the current workflow is sufficient.

• main branch - docker image will be flagged as "latest"
• tags - docker image will be flagged with the tag, i.e. "v1.0.5"

That mean there is 3 flavour instead of two, as i stated before in PR, usually :latest is same as the :vXXX , and keep follow the same with the most recent tag. But your flow :latest main branch, :vXXX tagged version, :develop is develop branch, and keep watching the cache you may still stuck on old version package.

[xavier-hernandez]

@martadinata666 Appreciate the input. I think you are 100% right on the personal preference point. I think right now this is what I feel the most comfortable with. At some point :latest will equal :vXXX and I might actually take out caching altogether.

[xavier-hernandez]

@just5ky tomorrow I'll update the readme file that the 3 docker image versions are available in my repo. Did you want me to remove the link to yours or will you continue to update your docker images?

[just5ky]

i will still keep my repo up-to-date.
If anyone wanna use my version, they can
i will only push latest & dev , every time you update your code, I just have to pull and merge in my repo, rest everything will be done automatically
@xavier-hernandez