-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
Support building Iron Bank Docker context #64336
Support building Iron Bank Docker context #64336
Conversation
…text" This reverts commit 2171b24.
Pinging @elastic/es-core-infra (:Core/Infra/Packaging) |
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.
Couple of comments but otherwise LGTM.
@@ -324,6 +362,8 @@ subprojects { Project subProject -> | |||
|
|||
final Architecture architecture = subProject.name.contains('aarch64-') ? Architecture.AARCH64 : Architecture.X64 | |||
final boolean oss = subProject.name.contains('oss-') | |||
// We can ignore Iron Bank at the moment as we don't |
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.
Just so I understand, we are effectively not building the iron bank image here becuase we have not added a corresponding "export' project for it, yes?
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.
Yes, there's no export task, and there won't be without a way to automatically build the image. That would require simulating the Iron Bank image build process.
When you have a chance, would you be able to upload a copy of the artifacts generated by the new ironbank target ? As for the "" placeholder, without knowing more what the future automation will look like, i'm ok with this approach. Keeping a blank value "" would be probably easier to standardize, but it's not as explicit as your current value. |
This PR adds support for building a Docker context for Iron Bank. It doesn't actually build the image - we could add that at a later stage, but this is an attempt to automate at least some of the process. Iron Bank is a lot like our UBI build, except it uses a hardened version of the full UBI image, not the minimal UBI image. They have particular requirements around how the Docker context should be arranged. The Docker build cannot fetch its own artefacts, but instead the context provides a descriptor that locates what is needed for the build. I also added a filter so that after performing expansions on the `Dockerfile`, we squash long runs on newlines together. This makes the output cleaner, while allowing us to break up the unprocessed `Dockerfile` for clarity.
Backport of #64336. This PR adds support for building a Docker context for Iron Bank. It doesn't actually build the image - we could add that at a later stage, but this is an attempt to automate at least some of the process. Iron Bank is a lot like our UBI build, except it uses a hardened version of the full UBI image, not the minimal UBI image. They have particular requirements around how the Docker context should be arranged. The Docker build cannot fetch its own artefacts, but instead the context provides a descriptor that locates what is needed for the build. I also added a filter so that after performing expansions on the `Dockerfile`, we squash long runs on newlines together. This makes the output cleaner, while allowing us to break up the unprocessed `Dockerfile` for clarity.
This PR adds support for building a Docker context for Iron Bank. It doesn't actually build the image - we could add that at a later stage, but this is an attempt to automate at least some of the process.
Iron Bank is a lot like our UBI build, except it uses a hardened version of the full UBI image, not the minimal UBI image. They have particular requirements around how the Docker context should be arranged. The Docker build cannot fetch its own artefacts, but instead the context provides a descriptor that locates what is needed for the build.
I also added a filter so that after performing expansions on the
Dockerfile
, we squash long runs on newlines together. This makes the output cleaner, while allowing us to break up the unprocessedDockerfile
for clarity.