Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add multi-arch native image and Mandrel image push steps #196

Closed
wants to merge 1 commit into from
Closed

Add multi-arch native image and Mandrel image push steps #196

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions .github/push-images.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,3 +10,39 @@ do
echo "Pushing ${IMG}"
docker push ${IMG}
done

manifest_push () {
local image=$1
local tag=$2

docker manifest create quay.io/quarkus/${image}:${tag} \
--amend quay.io/quarkus/${image}:${tag}-amd64 \
--amend quay.io/quarkus/${image}:${tag}-arm64
docker manifest push quay.io/quarkus/${image}:${tag}
}

# Manually combine manifests for multi-arch native builder images
if [[ $(docker images | grep quay.io/quarkus/ | grep "ubi-quarkus-native-image") ]]; then
manifest_push "ubi-quarkus-native-image" "22.0.0-java17"
manifest_push "ubi-quarkus-native-image" "22.0.0-java11"
manifest_push "ubi-quarkus-native-image" "22.0-java17"
manifest_push "ubi-quarkus-native-image" "22.0-java11"

manifest_push "ubi-quarkus-native-image" "22.1.0-java17"
manifest_push "ubi-quarkus-native-image" "22.1.0-java11"
manifest_push "ubi-quarkus-native-image" "22.1-java17"
manifest_push "ubi-quarkus-native-image" "22.1-java11"
fi

# Manually combine manifests for multi-arch mandrel images
if [[ $(docker images | grep quay.io/quarkus/ | grep "ubi-quarkus-mandrel") ]]; then
manifest_push "ubi-quarkus-mandrel" "22.0.0.2.Final-java17"
manifest_push "ubi-quarkus-mandrel" "22.0.0.2.Final-java11"
manifest_push "ubi-quarkus-mandrel" "22.0-java17"
manifest_push "ubi-quarkus-mandrel" "22.0-java11"

manifest_push "ubi-quarkus-mandrel" "22.1.0.0.Final-java17"
manifest_push "ubi-quarkus-mandrel" "22.1.0.0.Final-java11"
manifest_push "ubi-quarkus-mandrel" "22.1-java17"
manifest_push "ubi-quarkus-mandrel" "22.1-java11"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should definitely find a better way to figure out the tags, ideally fetching them from

quarkus-images/.github/mandrel-images.yaml

Line 4 in 5407633

versions:

If jbang is the preferred way I am OK with that. After all I never had to touch "push-images" before, so I would prefer the people actually maintaining it to decide what they prefer.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I first discussed this with @cescoffier, I agreed with your statement: let's make this a jbang script and consume the versions in yaml, but I don't think it'll really solve the little hardcoding done in the bash script.

Put it this way: none of the image versions that need to be created (e.g. mandrel 22.1.0.0.Final-java17 or graalvm 22.0.0-java17) are part of the versions that you pass in in the yaml. The versions that you pass in are the ones you build the traditional way (same for build and push) and then you have these extra overarching versions that are only used by push and created and pushed differently (e.g. docker manifest create... and docker manifest push).

So, I'm currently leaning towards keeping things as they are in the PR. One thing that complicates making wide ranging changes in the push side is that there's no real way to test it until you get the GH action to kick in and see if it works as expected. Note that I actually tested something very similar to this in my own repo's main branch and a custom GH action. That's how I ended up pushing multi-arch images to my own fork, see here.

Copy link
Member Author

@galderz galderz May 11, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's true as well that you could enhance the yaml to somehow add the multi arch tags (something akin to what happens with tags) and then have some kind of way of saying that this multi-arch tag is built out of these other tags. E.g.

multi-arch-tags:
  - id: 22.1-java17
    versions:
    - 22.1-java17-amd64
    - 22.1-java17-arm64
  - id: 22.1.0-java17
    versions:
    - 22.1.0-java17-amd64
    - 22.1.0-java17-arm64

fi
14 changes: 14 additions & 0 deletions .github/workflows/push-images.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,20 @@ jobs:
- .github/tooling-images.yaml
steps:
- uses: actions/checkout@v1
- name: Set up QEMU
uses: docker/setup-qemu-action@v1
- name: Set up Docker Buildx
id: buildx
uses: docker/setup-buildx-action@v1
with:
install: true
- name: Inspect builder
run: |
echo "Name: ${{ steps.buildx.outputs.name }}"
echo "Endpoint: ${{ steps.buildx.outputs.endpoint }}"
echo "Status: ${{ steps.buildx.outputs.status }}"
echo "Flags: ${{ steps.buildx.outputs.flags }}"
echo "Platforms: ${{ steps.buildx.outputs.platforms }}"
- name: Prerequisites
run: .github/ci-prerequisites.sh
- name: Build images
Expand Down