Skip to content
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

Conversation

seanabraham
Copy link
Contributor

@seanabraham seanabraham commented Jan 25, 2020

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 the war/bootWar tasks when applicable, the jar task when applicable, and always depends on the projects runtimeClasspath configuration.

Gradle allows tasks to depend on FileCollections (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 the FileCollection. Doing so with the runtimeClasspath configuration means Gradle will run all the tasks to get all the artifacts necessary to run this project, making it more efficient than using the assemble task which will often run slow, and unnecessary tasks. In particular, the main source set's runtimeClasspath's property includes the source set output appended to the project's runtimeClasspath configuration so depending on that obviates the need to run even manually run the classes 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.

FileCollection allFiles = mainSourceSet.getRuntimeClasspath().filter(File::exists);

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 of task.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 into jibDependencies.

This should resolve #2184

@googlebot

This comment has been minimized.

@seanabraham
Copy link
Contributor Author

@googlebot I signed it!

@googlebot

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);
Copy link
Contributor Author

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.

@loosebazooka
Copy link
Member

loosebazooka commented Jan 25, 2020

Nice, this is the better solution, so I'll close #2246. I'll take a deeper look in the next few days.

Copy link
Member

@loosebazooka loosebazooka left a 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!

@loosebazooka
Copy link
Member

integ tests look good too.

@seanabraham
Copy link
Contributor Author

@loosebazooka thanks for the review! I addressed the comments, and confirmed that the jibDependencies task doesn't show up in the gradlew tasks output. Let me know if there are any other changes you'd like to see.

Copy link
Member

@loosebazooka loosebazooka left a 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.

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.
@seanabraham seanabraham force-pushed the sean--fix-gradle-task-dependencies branch from 26649a1 to 2b7a205 Compare January 27, 2020 00:09
@seanabraham seanabraham requested review from chanseokoh and removed request for TadCordle and chanseokoh January 31, 2020 04:58
@loosebazooka
Copy link
Member

@seanabraham thanks again. I think adding jibDependencies as an explicit task is not something we want to commit to at the moment. Could you just use the previous mechanism. I understand that the plugin logic and tests become more complicated, but the surface of jib exposed to the user is reduced.

TaskProvider<Task> warTask = TaskCommon.getWarTaskProvider(projectAfterEvaluation);
TaskProvider<Task> bootWarTask =
TaskCommon.getBootWarTaskProvider(projectAfterEvaluation);
TaskProvider<Task> jibDependenciesTask = tasks.register(DEPENDENCIES_TASK_NAME);
Copy link
Member

@loosebazooka loosebazooka Jan 31, 2020

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

Copy link
Contributor Author

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

@seanabraham
Copy link
Contributor Author

seanabraham commented Feb 3, 2020

@loosebazooka I refactored to remove the jibDependencies task and instead have each of the jib tasks depend directly on relevant items (war, bootWar, etc. tasks and the runtimeClasspath configuration from the main source set). PTAL

@loosebazooka
Copy link
Member

Awesome, thanks @seanabraham

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Too many tasks executed on jib build
5 participants