-
Notifications
You must be signed in to change notification settings - Fork 1
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
Build multiarch #31
Build multiarch #31
Conversation
Thanks Zoey! However I'd like to keep the current build workflow and only change the promote to beta and prommote to latest workflows. Would that be possible? :) |
Also lets not change latest to latest-amd64, etc. Additionally, we will need to keep the latest-arm64 and beta-arm64 as otherwise currenty instances will not be able to update anymore... |
all for the channels develop, beta and latest |
I would not introduce this as we dont need it anymore with multiarch... |
no multiarch tag for the develop channel? |
yes, this is the most stable way that I see of doing this. |
yeah, we need to keep this for updat reasons |
should be done |
Thanks a lot! However in order to support this correctly, we would additionall need to adjust the logic in https://github.com/nextcloud/all-in-one/blob/main/php/src/Docker/DockerHubManager.php to use the in nextcloud/all-in-one#490 (comment) mentioned link and get the digest based on the architecture... |
Won't work, we can only bundle develop and develop-arm64 to beta, but not copy beta to latest this way |
I see, is this why you wanted to introduce amd64? |
Got it fixed through this: https://stackoverflow.com/a/73885289 |
The reason was to have a multiarch image inside the develop channel |
But a question: |
Only arm64 imo |
This option seems to be very new, since in the past I used regctl to copy multiarch images (since |
That's good, it would now make (if it works):
|
If you need a multiarch image inside the develop channel (for testing), you could try this:
should I create an additional workflow for this? |
Thanks for the offer but I think it is not necessary :) Edit: ah you mean before pushing to beta... I think it will still be fine... |
LGTM :) |
So not needed or did I misunderstand this? |
It should not be needed :) Now with the new endpoint where we get the digest we will likely need to get the correct arch anyway so if it works for single arch it should also work for multiarch |
Signed-off-by: Zoey <zoey@z0ey.de>
Co-authored-by: Simon L. <szaimen@e.mail.de>
@szaimen can you please check these suggestions? |
LGTM! I'll merge this shortly before the next beta release :) |
Sorry but I need to revert this as it breaks the update check. |
No problem, but is the update check or the manifest creation the problem? |
|
So somehow the digests did not match at all... |
I've tested on one of my images:
|
yes, so as you can see does the docker registry not return the correct digest somehow... |
The digest reports: |
Yes but the correct digest is not in the list of |
or am I misunderstanding something? |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Found a solution:
Commands:
|
This would require the old api implementation |
Okay, but how too get the amd64 digest in that case or is the docker api this somehow handling automatically even though we did not provide the arch at all? |
Additional Question: why is |
The digest is the on arm64 and amd64:
amd64:
|
arm64 returns only the digest of arm64, I don't understand the question? |
Ah I see. So the manifest digest is the same on arm64 and on amd64 for multiarch? |
Yes |
Okay, wow wouldn't have thought so. That makes things much easier, indeed! |
Can I create a new PR? I think in the mastercontainer the old implementation should work, when the accept header is set to this: |
Only one question, how does the mastercontainer check the digest of the current used image? |
it checks it the same like the docker service. It checks the repodigest of the image. |
Signed-off-by: Zoey zoey@z0ey.de
Based on: nextcloud/all-in-one#490 (reply in thread)
Should work, but not tested
I don't know, but maybe AIO needs support for the latest-amd64, beta-amd64 etc tags? (Internally)
It first created the ":develop" tag, after the "develop-arm64" tag was built, but the "develop-amd64" tag is available earlier