-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[DO NOT MERGE] Multi arch containers #43085
base: release/8.0.4xx
Are you sure you want to change the base?
[DO NOT MERGE] Multi arch containers #43085
Conversation
A few notes that we will need to handle based on my trials at baronfel/sdk-container-demo#15
|
Or |
_ContainerLabel=@(ContainerLabel, ';'); | ||
_ContainerPort=@(ContainerPort, ';'); | ||
_ContainerEnvironmentVariables=@(ContainerEnvironmentVariables, ';'); |
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 three Items can't be 'passed' into the inner build like this because they contain metadata that gets removed when they are converted back to properties. As a result, when parsed back into Items during _ParseParametersForPublishingSingleContainer
the Items exist but no longer have any of their useful values.
@rainersigwald is there a better pattern for computing properties and Items that should be provided to an Inner build?
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.
There's not really a good "push" model for items with metadata. You can "pull" via the return value of a target called with MSBuild; that might be an option here (to have the inner builds call back to the outer build to get the info). Otherwise you have to pass structured data and deserialize it on the other side (JSON or something).
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 an interesting question though - you could see for some of these (env var/arguments) might need to vary per-RID.
I tested the next round of changes and it's looking really good!
I noted two problems to dig into:
|
2. set mediaType of each image from manifest in CreateImageIndex 3. set arch and os from config in CreateImageIndex
The changes in this PR:
PublishContainer
target renamed to_PublishSingleContainer
_PublishMultiArchContainers
target that calls_PublishSingleContainer
for each arch and then creates image indexPublishContainer
target calls either_PublishSingleContainer
or_PublishMultiArchContainers
depending on a conditionCreateImageIndex
that creates the image index (manifest list it's same thing) and pushes to the remote registry.Notes:
docker
in order to create manifest list (image index) the images must be available in the remote registry. Forpodman
it is possible to do it locally. That is not part of these PR. It will be the next iteration.Testing:
Tested manually for docker hub registry, linux-x64 and linux-arm64 architectures