[Distribution Build Break] Related to upgrade to Gradle 7

[peternied]

Plugins are seeing error messages when building because of missing GlobalBuildInfoPlugin.

Reproduce with

• git checkout https://github.com/opensearch-project/opensearch-build && cd opensearch-build
• ./build.sh manifests/1.3.0/opensearch-1.3.0.yml

Error message

+ ./gradlew assemble --no-daemon --refresh-dependencies -DskipTests=true -Dopensearch.version=1.3.0 -Dbuild.snapshot=false -x ktlint
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: https://docs.gradle.org/6.6.1/userguide/gradle_daemon.html.
Daemon will be stopped at the end of the build stopping after processing

FAILURE: Build failed with an exception.

* Where:
Build file '/tmp/tmpdxxyybez/alerting/alerting/build.gradle' line: 34

* What went wrong:
A problem occurred evaluating project ':alerting'.
> Failed to apply plugin class 'org.opensearch.gradle.info.GlobalBuildInfoPlugin'.
   > Could not create plugin of type 'GlobalBuildInfoPlugin'.
      > Could not generate a decorated class for type GlobalBuildInfoPlugin.
         > org/gradle/internal/jvm/inspection/JvmInstallationMetadata

[peternied]

@reta Can you look into this, it might be related to recent changes you made We should have teams upgrade to the latest version of gradle resolve this opensearch-project/common-utils#101

[saratvemulapalli]

Looks like job-scheduler is failing to build because of changes in core.

A problem occurred evaluating root project 'opensearch-job-scheduler'.
> Failed to apply plugin class 'org.opensearch.gradle.info.GlobalBuildInfoPlugin'.
   > Could not create plugin of type 'GlobalBuildInfoPlugin'.
      > Could not generate a decorated class for type GlobalBuildInfoPlugin.
         > org/gradle/internal/jvm/inspection/JvmInstallationMetadata

The signature of GlobalBuildInfoPlugin changed with migration to Gradle 7.
Plugins should must upgrade to Gradle 7 to solve this, very likely this will impact all plugins.

Ref: opensearch-project/OpenSearch@93bd32b#diff-9f9d91bba5c4d429a0d%5B%E2%80%A6%5D3a40789ce3dd5c7bfc2f2R84

[reta]

@peternied @saratvemulapalli yes, we have discussed that under opensearch-project/OpenSearch#1630, the issues for all plugins are created opensearch-project/opensearch-plugins#107 and will be fixed shortly, it is difficult to support 6.x and 7.x at the same for OpenSearch builds, sorry for such inconsistency window

[dbbaughe]

@saratvemulapalli @reta

If this is a breaking change that breaks all plugins because of a change in core for the build tooling.. then perhaps we should revert the upgrade to Gradle 7 for now and introduce it in 2.0 instead of 1.3 where it might be more appropriate to introduce such a change.

@dblock @elfisher ^

[reta]

@dbbaughe we have touched on that here opensearch-project/OpenSearch#1630, the migration for plugins is (sadly) breaking but easy to address. The issue is two fold: because of the OpenSearch usage of old Gradle, plugin developers cannot use the never Gradle as well.

[dbbaughe]

@reta It doesn't matter if it's easy. It's breaking. If this isn't some critical security fix for our build tooling that requires us to bump the Gradle version then we shouldn't be introducing this bump into a minor release as it appears to break plugin builds. I'm not fully aware of the context of this change, so please feel free to add additional context here, but from the looks of it so far this should be reverted from 1.3 and kept only in 2.0 with additional steps for plugin developers in the 2.0 release notes to bump to a min version of Gradle 7 when migrating to 2.0.

[reta]

@dbbaughe sure, revert is easy, just please note that we are not talking just about 1.3 here but the whole 1.3+ line. We'll stuck with old Gradle for ages, anyway I would certainly let @dblock to make the call

[dblock]

1.3 is not shipping tomorrow and there's plenty of time to upgrade tooling - I didn't feel like we needed to consider that as a "breaking change" - why do you feel otherwise @dbbaughe? similarly we're moving from JDK 14 (non LTS) to 11, and the software continues to run on all versions

[reta]

@dblock just to clarify on "breaking change" - the plugin authors would need to update to Gradle 7 as well in order to build their plugins against 1.3.0-SNAPSHOT. The reason for that is OpenSearch tooling, specifically, org.opensearch.gradle.info.GlobalBuildInfoPlugin, that was using incubating Gradle 6.x APIs (thanks @dlvenable), wiped out in Gradle 7. Most (if not all) plugin use OpenSearch tooling, so @dbbaughe is right from this perspective - it is "breaking change", it was known and discussed here opensearch-project/OpenSearch#1622. Please let me know if more context or details are needed, thank you.

PS: As you rightly pointed out, all plugins we could update - will be updated.

[dblock]

Can I have some hands on whether this should be reverted from 1.x, and we'd rather defer the gradle upgrading work to 2.0?

[reta]

@dblock basically we have the following pros / cons:

• revert change for 1.x
  [+] plugins are not affected for 1.x line
  [-] plugin authors are constrained to use Gradle 6, no matter they would prefer to use Gradle 7+
  [-] plugin authors would have to migrate to Gradle 7+ in order to support 2.0+ (so this change is inevitable in long run)

• keeping the change for 1.x
  [+] absorb one time cost of migration
  [+] plugins could use same build tooling 1.x and 2.0+
  [-] plugins builds are affected for 1.x line and will fail

The two major features of Gradle 7, official JDK 17 support and Scala 3, may not be very important in the context of OpenSearch ecosystem right now.

[dblock]

I thought about this more and I think we should stick to our commitment for broad backwards compatibility in the case of the tooling. I'm inclined to revert this change on 1.x. @reta if you agree care to PR the change(s)?

[reta]

@dblock sure, no objections, on it

[dblock]

opensearch-project/OpenSearch#1657 reverted from 1.3