Tag arm images #490
Tag arm images #490
Conversation
| @@ -4,6 +4,7 @@ options: | |||
| machineType: 'E2_HIGHCPU_32' | |||
| env: | |||
| - DOCKER_CLI_EXPERIMENTAL=enabled | |||
| - BUILDX_NO_DEFAULT_ATTESTATIONS=1 | |||
There was a problem hiding this comment.
Without this multi-arch images creates two additional image with default attestation.
https://screenshot.googleplex.com/8aaumgjd3o9h2hL
There was a problem hiding this comment.
What are the default attestations? Do we not want them and will removing them cause any issues?
| @@ -15,22 +16,10 @@ steps: | |||
| args: | |||
| - 'buildx' | |||
| - 'create' | |||
| - '--use' # Create and use builder in one step | |||
There was a problem hiding this comment.
Same with these, what are they doing?
There was a problem hiding this comment.
Combining multi-arch steps 1,2,3 into 1. Where we create a builder for multi-arch implementation and bootstrap it for using in the multi-arch build steps below
| return t | ||
|
|
||
| # Make all the tags and save them | ||
| tags={} | ||
| multi_arch_tags={} | ||
| multi_arch_arm_tags={} | ||
| multi_arch_amd_tags={} |
There was a problem hiding this comment.
Actually one is for arm images and the other is for amd.
| id: multi_arch_debian_slim | ||
| args: ['buildx', 'build', '--build-arg', 'CLOUD_SDK_VERSION=$_CLI_VERSION', '--platform', 'linux/arm64,linux/amd64', '-t', 'us-docker.pkg.dev/google.com/cloudsdktool/gcr.io/google-cloud-cli:slim', '-t', 'us-docker.pkg.dev/google.com/cloudsdktool/gcr.io/google-cloud-cli:$TAG_NAME-slim', '-t', 'us-docker.pkg.dev/google.com/cloudsdktool/gcr.io/google-cloud-cli:$TAG_NAME-slim-$_DATE', '-t', 'us-docker.pkg.dev/google.com/cloudsdktool/us.gcr.io/google-cloud-cli:slim', '-t', 'us-docker.pkg.dev/google.com/cloudsdktool/us.gcr.io/google-cloud-cli:$TAG_NAME-slim', '-t', 'us-docker.pkg.dev/google.com/cloudsdktool/us.gcr.io/google-cloud-cli:$TAG_NAME-slim-$_DATE', '-t', 'europe-docker.pkg.dev/google.com/cloudsdktool/eu.gcr.io/google-cloud-cli:slim', '-t', 'europe-docker.pkg.dev/google.com/cloudsdktool/eu.gcr.io/google-cloud-cli:$TAG_NAME-slim', '-t', 'europe-docker.pkg.dev/google.com/cloudsdktool/eu.gcr.io/google-cloud-cli:$TAG_NAME-slim-$_DATE', '-t', 'asia-docker.pkg.dev/google.com/cloudsdktool/asia.gcr.io/google-cloud-cli:slim', '-t', 'asia-docker.pkg.dev/google.com/cloudsdktool/asia.gcr.io/google-cloud-cli:$TAG_NAME-slim', '-t', 'asia-docker.pkg.dev/google.com/cloudsdktool/asia.gcr.io/google-cloud-cli:$TAG_NAME-slim-$_DATE', 'debian_slim/', '--push'] | ||
| waitFor: ['multi_arch_step3'] | ||
| id: multi_arch_debian_slim_arm |
There was a problem hiding this comment.
This is a fairly big refactoring, what motivated us to split up the tags into separate build steps rather than building the multi-arch images at once? I agree this makes it easier to discern but at least for this review the density makes it hard for me to be 100% certain there's no breaking changes in here.
There was a problem hiding this comment.
Understood. Well the fact that it is not changing the Dockerfile(s), i believe the images itself are not changed at all.
With my research I did not find any way of automatically tagging the images postfacto once the images are created. So our current approach of building both multi-arch images together will create at least two untagged images (one for arm and one for amd).
To resolve that what we are doing here is building the arm image and amd image separately (with their own tag) and then combining them into our final image with the appropriate tags.
There was a problem hiding this comment.
Why does it produce untagged images? Shouldn't it only build image tags specified by the -t flag?
Enabled tagging for multi-arch images in the artifact registry to make sure there are no untagged images in the registry.