You have a nice straightforward approach. I like it.
The docker organization on GitHub has several useful actions you might look at if you need to do something more complex, such as multiplatform images or pushing to multiple registries. For example, here is a link to a workflow in one of my repos where on releases I build a multiplatform image and push to both Docker Hub as well as the GitHub Container Registry. The docker/login-action is especially useful for that in combination with the docker/build-push-action. If you are pushing to N registries, you need N applications of the login-action, but just one build-push-action.
Links to the specific docker actions I'm using are below:
GitHub Action to build and push Docker images with Buildx
About
GitHub Action to build and push Docker images with Buildx
with full support of the features provided by Moby BuildKit
builder toolkit. This includes multi-platform build, secrets, remote cache, etc
and different builder deployment/namespacing options.
In the examples below we are also using 3 other actions:
setup-buildx action will
create and boot a builder using by default the docker-container driver
This is not required but recommended using it to be able to build
multi-platform images, export cache, etc.
setup-qemu action can be
useful if you want to add emulation support with QEMU to be able…
This action will create and boot a builder that can be used in the following
steps of your workflow if you're using Buildx or the build-push action
By default, the docker-container driver
will be used to be able to build multi-platform images and export cache using
a BuildKit container.
name: cion:
push:
jobs:
buildx:
runs-on: ubuntu-lateststeps:
-
name: Checkoutuses: actions/checkout@v3
-
# Add support for more platforms with QEMU (optional)# https://github.com/docker/setup-qemu-actionname: Set up QEMUuses: docker/setup-qemu-action@v2
-
name: Set up Docker Buildxuses: docker/setup-buildx-action@v2
I am a full-stack developer and love coding and tooling. At my work, I am often the person who is developing and setting up dev and production environments.
I knew I can do better than what I have! I very recently got into githubworkflows, I am not used to using premade jobs. In my company we use gitlab for our workflow and there you usually code it yourself. But I definitly gonna check the repositories out!
I already had a look into your workflow file. I must admit I find my solution more readable. I miss YAML Anchors so I can make it even more readable.
But I want to improve it and condense it to one file and yes currently I am just deplying to one registry, but this might change!
If you are hoping to condense the 2 workflows into one, you can probably use a conditional step that checks which event triggered that run. For example:
- if: ${{ github.event_name == 'push' }}run:# thing you want to do on a push
And then something similar for the schedule event.
I am a full-stack developer and love coding and tooling. At my work, I am often the person who is developing and setting up dev and production environments.
Your workflow is very readable. The step I named prepare is almost certainly more complicated than it needs to be. It is getting the release tag from the github release that triggered the workflow, and generating a list of tags for the image. From a github release tag of let's say v3.2.1, I'm dropping the v and tagging the docker image with: latest, 3.2.1, 3.2, and 3 (the step that does all of that looks very messy).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You have a nice straightforward approach. I like it.
The docker organization on GitHub has several useful actions you might look at if you need to do something more complex, such as multiplatform images or pushing to multiple registries. For example, here is a link to a workflow in one of my repos where on releases I build a multiplatform image and push to both Docker Hub as well as the GitHub Container Registry. The docker/login-action is especially useful for that in combination with the docker/build-push-action. If you are pushing to N registries, you need N applications of the login-action, but just one build-push-action.
Links to the specific docker actions I'm using are below:
GitHub Action to login against a Docker registry
About
GitHub Action to login against a Docker registry.
Usage
Docker Hub
To authenticate against Docker Hub it's strongly recommended to create a personal access token as an alternative to your password.
GitHub Container Registry
To authenticate against the GitHub Container Registry, use the
GITHUB_TOKENfor the best security and experience.GitHub Action to build and push Docker images with Buildx
About
GitHub Action to build and push Docker images with Buildx with full support of the features provided by Moby BuildKit builder toolkit. This includes multi-platform build, secrets, remote cache, etc and different builder deployment/namespacing options.
Usage
In the examples below we are also using 3 other actions:
setup-buildxaction will create and boot a builder using by default thedocker-containerdriver This is not required but recommended using it to be able to build multi-platform images, export cache, etc.setup-qemuaction can be useful if you want to add emulation support with QEMU to be able…GitHub Action to set up Docker Buildx
About
GitHub Action to set up Docker Buildx.
This action will create and boot a builder that can be used in the following steps of your workflow if you're using Buildx or the
build-pushaction By default, thedocker-containerdriver will be used to be able to build multi-platform images and export cache using a BuildKit container.nodesoutputUsage
Advanced usage
GitHub Action to configure QEMU support
About
GitHub Action to install QEMU static binaries.
Usage
Customizing
inputs
Following inputs can be used as
step.withkeysimagetonistiigi/binfmt:latest)platformsarm64,riscv64,arm; defaultall)outputs
Following outputs are available
platformsContributing
Want to contribute? Awesome! You can find information about contributing to this project in the CONTRIBUTING.md
Hey thank you for your feedback!
I knew I can do better than what I have! I very recently got into githubworkflows, I am not used to using premade jobs. In my company we use gitlab for our workflow and there you usually code it yourself. But I definitly gonna check the repositories out!
I already had a look into your workflow file. I must admit I find my solution more readable. I miss YAML Anchors so I can make it even more readable.
But I want to improve it and condense it to one file and yes currently I am just deplying to one registry, but this might change!
If you are hoping to condense the 2 workflows into one, you can probably use a conditional step that checks which event triggered that run. For example:
And then something similar for the schedule event.
I thought of doing it in a similar way! :D But it didn't work yet. I will revisit this next week.
Your workflow is very readable. The step I named prepare is almost certainly more complicated than it needs to be. It is getting the release tag from the github release that triggered the workflow, and generating a list of tags for the image. From a github release tag of let's say v3.2.1, I'm dropping the v and tagging the docker image with: latest, 3.2.1, 3.2, and 3 (the step that does all of that looks very messy).