-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Replace assemble task dependency with runtimeClasspath #2247
Replace assemble task dependency with runtimeClasspath #2247
Conversation
This comment has been minimized.
This comment has been minimized.
@googlebot I signed it! |
This comment has been minimized.
This comment has been minimized.
Assert.assertEquals(warTask, taskProviders.get(0).get()); | ||
TaskProvider<?> jibDependenciesTaskProvider = | ||
(TaskProvider<?>) tasks.getByPath(taskName).getDependsOn().iterator().next(); | ||
Assert.assertEquals(jibDependenciesTaskProvider.get(), jibDependenciesTask); |
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 test changes (and the ones below) are now checking for whether the jibDependencies
task depends on the requisite tasks (like the warTask
or bootWarTask
below) and whether all the jib tasks depend on jibDependencies
which is the only task they need to depend on now.
Nice, this is the better solution, so I'll close #2246. I'll take a deeper look in the next few days. |
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.
Awesome, just some really minor things, but thanks for doing this!
jib-gradle-plugin/src/main/java/com/google/cloud/tools/jib/gradle/JibPlugin.java
Outdated
Show resolved
Hide resolved
jib-gradle-plugin/src/test/java/com/google/cloud/tools/jib/gradle/JibPluginTest.java
Outdated
Show resolved
Hide resolved
jib-gradle-plugin/src/test/java/com/google/cloud/tools/jib/gradle/JibPluginTest.java
Outdated
Show resolved
Hide resolved
integ tests look good too. |
@loosebazooka thanks for the review! I addressed the comments, and confirmed that the |
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 actually in the middle of prepping a release. We'll have to wait on that before we merge this in.
jib-gradle-plugin/src/main/java/com/google/cloud/tools/jib/gradle/JibPlugin.java
Outdated
Show resolved
Hide resolved
This introduces a new lifecycle task called "jibDependencies" that all the jib tasks depend on and it in turn depends on any requiste tasks / configurations. In particular, jibDependencies will depend on the war/bootWar tasks when applicable, the jar task when applicable and always the runtime configuration. Depending directly on the runtime configuration allows Gradle to add to the task graph appropriately to provide all the artifacts that are specified in that configuration, making it more efficient than using the assemble task.
26649a1
to
2b7a205
Compare
@seanabraham thanks again. I think adding |
TaskProvider<Task> warTask = TaskCommon.getWarTaskProvider(projectAfterEvaluation); | ||
TaskProvider<Task> bootWarTask = | ||
TaskCommon.getBootWarTaskProvider(projectAfterEvaluation); | ||
TaskProvider<Task> jibDependenciesTask = tasks.register(DEPENDENCIES_TASK_NAME); |
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.
Sorry, after thinking about this while we were doing the release, I realized I'm not quite convinced this is how we want to do this. Maybe in the future... but the problem is going backwards/deprecating something has a high cost.
Can we just use the mechanism used previously: https://github.com/GoogleContainerTools/jib/pull/2247/files#diff-aef8bf567c91df6622aa0ea29ed0c682L175
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.
Sure, I can make that change
@loosebazooka I refactored to remove the |
Awesome, thanks @seanabraham |
This introduces a new lifecycle task called
jibDependencies
(the name can really be anything, that was just what I came up with) that all the jib tasks depend on and it in turn depends on any requisite tasks / configurations. Being a lifecycle task, it doesn't have any task action itself and essentially exists as a convenient hook for other dependencies. In particular,jibDependencies
will depend on thewar
/bootWar
tasks when applicable, thejar
task when applicable, and always depends on the projectsruntimeClasspath
configuration.Gradle allows tasks to depend on
FileCollection
s (rather than just tasks). When doing so Gradle expands the task graph expands to include all the necessary tasks to produce the files listed in theFileCollection
. Doing so with theruntimeClasspath
configuration means Gradle will run all the tasks to get all the artifacts necessary to run this project, making it more efficient than using theassemble
task which will often run slow, and unnecessary tasks. In particular, the main source set'sruntimeClasspath
's property includes the source set output appended to the project'sruntimeClasspath
configuration so depending on that obviates the need to run even manually run theclasses
task. (See https://docs.gradle.org/current/userguide/java_plugin.html#sec:source_set_properties)If we only want to conditionally depend on the runtime classpath I'm happy to make that change though I assume it's never really going to be a bad thing even in the case of the
war
based projects.Also, for what it's worth — jib itself uses the
runtimeClasspath
to get the list of files to add to the container so it makes sense to use that same collection to set up the task dependencies.jib/jib-gradle-plugin/src/main/java/com/google/cloud/tools/jib/gradle/GradleProjectProperties.java
Line 174 in d3615a6
There are a few different potential approaches here so I'm happy to make changes to go with a different approach. For example, we don't have to introduce the
jibDependencies
task but it made the implementation a little cleaner and also made it so that the changes to tests were minimal (some of them make assumptions about the contents oftask.getDependsOn()
which are no longer true when tasks depend on configurations for example). It might also be useful in the future if there are new dependencies since they can all hook intojibDependencies
.This should resolve #2184