-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Include log4j transform jar in docker build context tasks #69808
Include log4j transform jar in docker build context tasks #69808
Conversation
Pinging @elastic/es-delivery (Team:Delivery) |
@elasticmachine update branch |
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 a clarifying question for my own edification.
@@ -11,4 +20,8 @@ tasks.register("buildIronBankDockerBuildContext", Tar) { | |||
// We always treat Iron Bank builds as local, because that is how they | |||
// are built | |||
with dockerBuildContext(Architecture.X64, false, DockerBase.IRON_BANK, true) | |||
|
|||
into('scripts') { | |||
from configurations.transformLog4jJar |
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.
Why are we including this a second time again?
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.
We're not - in distribution/docker/build.gradle
, the jar is copied by the copy*DockerContext
task. That task also calls the extension method dockerBuildContext
, like the standalone context subprojects do.
The whole setup here is a bit weird. AFAICT, it exists so that we can generate a Docker context without having to do all the rest of the build. However, and again AFAICT, because we share most of the build context logic via an extension method, it can't (cleanly?) access configurations when called from a subproject. At least, when I tried to just move the jar copy to dockerBuildContext
, Gradle got angry with me. Suggestions welcome!
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.
Yeah, I think really the "solution" here is to ditch the separate projects just for creating the context and just make that a separate task in the associated project. I'm not completely certain why we went with this pattern to begin with other than creating more projects means better parallel execution but copying contexts isn't particularly expensive and DockerBuild
can already be executed concurrently w/ other tasks in the same project.
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.
We may be building things these way partly for the release-manager - we need to coordinate there before changing this.
…nto iron-bank-docker-improvements
Ensure that the log4j transform jar is included in the generated Docker build context. Also makes some small fixes to the Iron Bank Dockerfile.
Ensure that the log4j transform jar is included in the generated Docker build context. Also makes some small fixes to the Iron Bank Dockerfile.
Ensure that the log4j transform jar is included in the generated Docker build context. Also makes some small fixes to the Iron Bank Dockerfile.
When updating our Iron Bank image for 7.11.1, I realised that we weren't including the log4j transform jar in the build context. This PR fixes that, along with some Dockerfile tweaks.
Edit: turns out we need this PR to fix #69924.