-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a makefile command to assist with multi-arch builds #68
base: main
Are you sure you want to change the base?
Add a makefile command to assist with multi-arch builds #68
Conversation
|
||
# Builds multiple architectures at once. | ||
# Requires docker buildx and QEMU to be configured. | ||
# Because of how docker buildx works, in that it _must_ push when it builds, push is the default of this task. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand why a push is required. Why do we want our build command to automatically push the image?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a nuance of how buildx
works. It doesn't allow for building first, then pushing later, so, if you want to push the image that is produced by the multi-arch build, it has to be done at build time with this flag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ultimately, this buildx
tasks should be what is used for CI/CD to build and push multi-arch images, and the old build
and push
tasks can be used for testing / development things.
Makefile
Outdated
echo "VERSION is required"; \ | ||
exit 1; \ | ||
fi | ||
docker buildx build --platform linux/amd64,linux/arm64 --push . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these the only two platforms we want to support initially?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these 2 platforms are the easiest to support out of the gate, I figured more could be added later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, oops, just realized that I forgot the tags, I think we need to add this to the command: -t $(IMAGE_REPO):$$VERSION
Sorry for the delay on this. This looks good, but could you verify if you've tested this out manually? Or better yet, could you add a couple of steps to the CI pipeline to test out different multi-arch builds? |
@trstringer - would you be open to re-working the CI pipeline to help automate the build, release, deploy pipeline? That is pretty much the only way to work this into the CI pipeline. Maybe the push to main can cause a build and publish as I have tested this locally as well, but, open to your thoughts on the above. It would also probably make maintaining this project a lot easier for you the more that is automated. |
Bumping this @trstringer - do you want to automate this whole build pipeline for releasing? Last I checked it seems like none of this release build is automated. That direction would make the most sense and then this could be auto-done from CI. |
bump-type: | ||
type: choice | ||
description: The position of the version to be bumped. | ||
options: | ||
- patch | ||
- minor | ||
- major | ||
tag_to_move: | ||
type: choice | ||
description: The generic tag to be advanced. | ||
options: | ||
- v1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Options to select which part of the version to bump, and the generic tag to move on running this job.
- name: Bump version and push tag | ||
id: tag_version | ||
uses: mathieudutour/github-tag-action@v6.1 | ||
with: | ||
github_token: ${{ secrets.GITHUB_TOKEN }} | ||
default_bump: ${{ github.event.inputs.bump-type }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will select the new version and tag the repo
VERSION: ${{ steps.tag_version.outputs.new_version }} | ||
run: make buildx |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use that new version for the multi-arch build
git config user.email "action@github.com" | ||
- name: Tag new target | ||
run: git tag -f ${{ github.event.inputs.tag_to_move }} ${{ github.event.inputs.target }} | ||
- name: Push new tag |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will advance the v1
tag to this new version
Bumping to @trstringer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great!
Add a
buildx
makefile command that leveragesdocker buildx
to make multi-architecture images.--platform
can be any platforms that are the intersect of all base images used in the Dockerfile, but intel chips vs. arm chips is a great start, and should be supported with no additional effort.Note that the machine that runs this command will need to have both buildx configured, and probably QEMU in order to emulate the differing architectures. Here's some additional details explaning
buildx
: https://docs.docker.com/build/building/multi-platform/I would have also added this to the CI, but it looks like github actions isn't configured to build the final artifacts or deploy those. Let me know if you're interested in further automating this in some fashion!This indirectly addresses #54, but doesn't do anything to run this to create the actual artifacts.This adds a new release job that should take care of the multi-arch builds, release tagging, etc. to address #54