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

Gradle plugin opensearch.pluginzip Add implicit dependency. #3189

Merged
merged 7 commits into from
May 5, 2022
Merged

Gradle plugin opensearch.pluginzip Add implicit dependency. #3189

merged 7 commits into from
May 5, 2022

Conversation

prudhvigodithi
Copy link
Member

@prudhvigodithi prudhvigodithi commented May 4, 2022

Signed-off-by: pgodithi [email protected]

Description

This fix will remove the following warning's during runtime

Execution optimizations have been disabled for task ':publishPluginZipPublicationToZipStagingRepository' to ensure correctness due to the following reasons:
  - Gradle detected a problem with the following location: 'opensearch-plugin-template-java/build/distributions/rename-unspecified.pom'. Reason: Task ':publishPluginZipPublicationToZipStagingRepository' uses this output of task ':generatePomFileForNebulaPublication' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.4.2/userguide/validation_problems.html#implicit_dependency for more details about this problem.
> Task :validatePluginZipPom FAILED
Execution optimizations have been disabled for task ':validatePluginZipPom' to ensure correctness due to the following reasons:
  - Gradle detected a problem with the following location: '/usr/share/opensearch/git/opensearch-plugin-template-java/build/distributions/rename-unspecified.pom'. Reason: Task ':validatePluginZipPom' uses this output of task ':generatePomFileForNebulaPublication' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.4.2/userguide/validation_problems.html#implicit_dependency for more details about this problem.
name is missing in [/usr/share/opensearch/git/opensearch-plugin-template-java/build/distributions/rename-unspecified.pom]
description is missing in [/usr/share/opensearch/git/opensearch-plugin-template-java/build/distributions/rename-unspecified.pom]
licenses is empty in [/usr/share/opensearch/git/opensearch-plugin-template-java/build/distributions/rename-unspecified.pom]
developers is empty in [/usr/share/opensearch/git/opensearch-plugin-template-java/build/distributions/rename-unspecified.pom]
Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

Issues Resolved

#3183
opensearch-project/opensearch-plugin-template-java#31

Check List

  • New functionality includes testing.
    • All tests pass
  • New functionality has been documented.
    • New functionality has javadoc added
  • Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Signed-off-by: pgodithi <[email protected]>
@prudhvigodithi prudhvigodithi requested review from a team and reta as code owners May 4, 2022 21:11
@opensearch-ci-bot
Copy link
Collaborator

❌   Gradle Check failure b9f2e3a
Log 5009

Reports 5009

Signed-off-by: pgodithi <[email protected]>
@opensearch-ci-bot
Copy link
Collaborator

❌   Gradle Check failure 1b5f1ba
Log 5010

Reports 5010

@opensearch-ci-bot
Copy link
Collaborator

❌   Gradle Check failure 2402d78
Log 5011

Reports 5011

@prudhvigodithi
Copy link
Member Author

Hey @reta can you please validate this, this should remove those generate warning's.
@dblock

@opensearch-ci-bot
Copy link
Collaborator

✅   Gradle Check success b7c93f0
Log 5013

Reports 5013

configMaven(project);
Task validatePluginZipPom = project.getTasks().findByName("validatePluginZipPom");
if (validatePluginZipPom != null) {
project.getTasks().getByName("validatePluginZipPom").mustRunAfter("generatePomFileForNebulaPublication");
Copy link
Collaborator

@reta reta May 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious, why mustRunAfter but not dependsOn? We do not rely on any order, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mustRunAfter controls the execution order of tasks explicitly, so this ensures the task generatePomFileForNebulaPublication is called before the validatePluginZipPom and publishPluginZipPublicationToZipStagingRepository

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dependsOn does the same, mustRunAfter mandates that task has to run exactly in order after the task in question: I don't think we have such exact order requirements, dependsOn should be sufficient

Copy link
Member Author

@prudhvigodithi prudhvigodithi May 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mustRunAfter would ensure that task has been called out before those tasks. I have tested with mustRunAfter and I dont see the warnings anymore, as mustRunAfter calls that task before the dependent tasks @reta

Copy link
Member Author

@prudhvigodithi prudhvigodithi May 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But both works here 🙂
I'm fine with mustRunAfter or dependsOn, open for the change thoughts @reta @dblock ?:)

Copy link
Collaborator

@reta reta May 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest to switch to dependsOn, it introduces implicit dependencies (which is what we need, because our publication depends on it) [1]:

A task may have dependencies on other tasks or might be scheduled to always run after another task. Gradle ensures that all task dependencies and ordering rules are honored when executing tasks, so that the task is executed after all of its dependencies and any "must run after" tasks have been executed.

but mustRunAfter does merely controls the order [2]:

When you use the “must run after” ordering rule you specify that taskB must always run after taskA, whenever both taskA and taskB will be run.

The difference is actually very easy to demonstrate: if you just run a single publishPluginZipPublicationToZipStagingRepository task, none of the mustRunAfter tasks will be executed (notice generatePomFileForNebulaPublication is not there):

./gradlew -m publishPluginZipPublicationToZipStagingRepository 
:generateNotice SKIPPED                                                                        
:compileJava SKIPPED                                                                                                                                                                          
:processResources SKIPPED                                                                      
:classes SKIPPED                                                                               
:jar SKIPPED                                                                                   
:copyPluginPropertiesTemplate SKIPPED                                                          
:pluginProperties SKIPPED                                                                      
:bundlePlugin SKIPPED                                                                          
:generatePomFileForPluginZipPublication SKIPPED                                                
:publishPluginZipPublicationToZipStagingRepository SKIPPED     

Now, using dependsOn (notice generatePomFileForNebulaPublication is there):

./gradlew -m publishPluginZipPublicationToZipStagingRepository 
:generateNotice SKIPPED
:compileJava SKIPPED
:processResources SKIPPED
:classes SKIPPED
:jar SKIPPED
:copyPluginPropertiesTemplate SKIPPED
:pluginProperties SKIPPED
:bundlePlugin SKIPPED
:generatePomFileForNebulaPublication SKIPPED
:generatePomFileForPluginZipPublication SKIPPED
:publishPluginZipPublicationToZipStagingRepository SKIPPED

Hope it is sufficient to justify dependsOn usage.

[1] https://docs.gradle.org/current/dsl/org.gradle.api.Task.html#N18A16
[2] https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:ordering_tasks

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But both works here slightly_smiling_face

I hope the examples above help to clarify when it does not work

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the info @reta .
-m shows the task actions disabled, here our initial error is because we have a task generatePomFileForNebulaPublication that has been not called and these validatePluginZipPom & publishPluginZipPublicationToZipStagingRepository actually uses the output of generatePomFileForNebulaPublication, using mustRun will ensure this task generatePomFileForNebulaPublication has been invoked when ever the tasks validatePluginZipPom & publishPluginZipPublicationToZipStagingRepository are triggered, which should solve the output dependency, hence I mentioned running build should work, even though it does not show with -m output mustRun ensures it will execute the task.

But that said dependsOn should also work as we are adding exclusive graph dependency, I have updated my latest commit with dependsOn and ran few plugins build.sh and runs fine, please check @reta

if (validatePluginZipPom != null) {
project.getTasks().getByName("validatePluginZipPom").mustRunAfter("generatePomFileForNebulaPublication");
}
Task publishPluginZipPublicationToZipStagingRepository = project.getTasks()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should not use exact task name here but rely on the task type as per [1]:

          project.getTasks().withType(PublishToMavenRepository.class).configureEach(t -> {
                if (t.getPublication().getName().equals(PUBLICATION_NAME)) {
                    t.dependsOn(pomFileTask);
                }
            });

The reason for it is that we may publish to different repositories (fe local Maven) and that would be different task name, still requiring same task dependencies.

[1] https://github.com/opensearch-project/OpenSearch/pull/3183/files

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, I already have PUBLICATION_NAME var declared I can use that. I will push the change shortly.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @reta I assumed wrong, my bad, here we should be good, using this Plugin we dont push to any other repos, its strictly to pluginZip repo that generates fixed task publishPluginZipPublicationToZipStagingRepository, hence we should be good to hardcode, initially I have created few utils that can identify the PUBLICATION_NAME and taskname, but since its only single publication here using this plugin, I have had some conversations in this merged PR to hard code things, so long story short we should be good to hardcode task names.

Signed-off-by: pgodithi <[email protected]>
@prudhvigodithi
Copy link
Member Author

Thanks @reta

@opensearch-ci-bot
Copy link
Collaborator

✅   Gradle Check success fa56ddd
Log 5044

Reports 5044

@dblock dblock merged commit 2fe2e37 into opensearch-project:main May 5, 2022
@dblock
Copy link
Member

dblock commented May 5, 2022

@reta You should feel free to merge anything that you see fit without any additional approvals.

@dblock dblock added the backport 2.x Backport to 2.x branch label May 5, 2022
opensearch-trigger-bot bot pushed a commit that referenced this pull request May 5, 2022
* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add dependsOn

Signed-off-by: pgodithi <[email protected]>
(cherry picked from commit 2fe2e37)
@dblock dblock added the backport 2.0 Backport to 2.0 branch label May 5, 2022
opensearch-trigger-bot bot pushed a commit that referenced this pull request May 5, 2022
* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add dependsOn

Signed-off-by: pgodithi <[email protected]>
(cherry picked from commit 2fe2e37)
@reta
Copy link
Collaborator

reta commented May 5, 2022

@reta You should feel free to merge anything that you see fit without any additional approvals.

Thanks @dblock! I thought we are merging with 2 approvals (no restrictions on that, just general observation), no?

@dblock
Copy link
Member

dblock commented May 6, 2022

@reta You should feel free to merge anything that you see fit without any additional approvals.

Thanks @dblock! I thought we are merging with 2 approvals (no restrictions on that, just general observation), no?

Nah, I think we relaxed that a while ago.

peterzhuamazon pushed a commit that referenced this pull request May 7, 2022
…#3211)

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add dependsOn

Signed-off-by: pgodithi <[email protected]>
(cherry picked from commit 2fe2e37)

Co-authored-by: Prudhvi Godithi <[email protected]>
peterzhuamazon pushed a commit that referenced this pull request May 7, 2022
…#3212)

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add implicit dependency

Signed-off-by: pgodithi <[email protected]>

* Add dependsOn

Signed-off-by: pgodithi <[email protected]>
(cherry picked from commit 2fe2e37)

Co-authored-by: Prudhvi Godithi <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport 2.x Backport to 2.x branch backport 2.0 Backport to 2.0 branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants