Capture build scans on ge.apache.org to benefit from deep build insights

[clayburn]

Description

@dsmiley - This is the similar PR to apache/lucene#12293

This PR publishes a build scan for every CI build on Jenkins and GitHub Actions and for every local build from an authenticated Apache committer. The build will not fail if publishing fails.

The build scans of the Apache Solr project are published to the Gradle Enterprise instance at ge.apache.org, hosted by the Apache Software Foundation and run in partnership between the ASF and Gradle. This Gradle Enterprise instance has all features and extensions enabled and is freely available for use by the Apache Solr project and all other Apache projects.

This pull request enhances the functionality of publishing build scans to the publicly available scans.gradle.com by instead publishing build scans to ge.apache.org. On this Gradle Enterprise instance, Apache Solr will have access not only to all of the published build scans but other aggregate data features such as:

• Dashboards to view all historical build scans, along with performance trends over time
• Build failure analytics for enhanced investigation and diagnosis of build failures
• Test failure analytics to better understand trends and causes around slow, failing, and flaky tests

Please let me know if there are any questions about the value of Develocity or the changes in this pull request and I’d be happy to address them.

Checklist

Please review the following and check all that apply:

• I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
• I have created a Jira issue and added the issue ID to my pull request title.
• I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
• I have developed this patch against the main branch.
• I have run ./gradlew check.
• I have added tests for my changes.
• I have added documentation for the Reference Guide

[clayburn]

@dsmiley - I do not know the best way to address the Crave workflow. In order for it publish a build scan, it needs to have the access key where the build is running. I'm not sure it is a good idea to send the org-level access key to the Crave hosted runner, and I don't know enough about Crave to know how to do this. But it would be valuable to capture the build from that runner as well. What do you think?

[dsmiley]

If the build scan is a file that can be generated from the Gradle build (without access to GE), then this file could be moved back to the GitHub Action runner machine (which does have access to GE) to send it to GE.

[clayburn]

@dsmiley - this is a good idea. While we don't have first-class, documented support for moving the build scan data around on disk, I think it might be possible. I will investigate and get back to you.

[dsmiley]

I see this enables the build cache by default, which hopefully is a big positive benefit, at the expense of some local disk and risks of a misconfigured build leading to accidental caching. Note that this topic has been raised before: https://issues.apache.org/jira/browse/SOLR-15603 which defaults to false via commented out part of gradle.properties. Solr's build (and Lucene) generates on first build from a template which mentions org.gradle.caching. That should probably be removed entirely if we're going to enable build caching in this new ge.gradle file.

Even if the Crave integration is lacking; I don't think that should hold this up.

[clayburn]

I see this enables the build cache by default, which hopefully is a big positive benefit, at the expense of some local disk and risks of a misconfigured build leading to accidental caching. Note that this topic has been raised before: issues.apache.org/jira/browse/SOLR-15603 which defaults to false via commented out part of gradle.properties. Solr's build (and Lucene) generates on first build from a template which mentions org.gradle.caching. That should probably be removed entirely if we're going to enable build caching in this new ge.gradle file.

This change actually will not. You still need the org.gradle.caching=true property for the configuration here to take effect. When that is true, then the configuration in this PR will be applied.

Even if the Crave integration is lacking; I don't think that should hold this up.

I've done a little investigation on this so far, but without success. It would involve pulling files out of Gradle User Home back to the GitHub Actions runner. The crave pull command doesn't seem to let me access $HOME, which makes sense. I still have some avenues to explore, but I would not let that hold up this PR.

[dsmiley]

It'd be nice if the target path for the scan could be configurable.

What's involved in having tests balance better across runners? Would that make sense in a separate PR?

[clayburn]

It'd be nice if the target path for the scan could be configurable.

As of now, the storage of the previous scan is really an implementation detail to support the buildScanPublishPrevious command. It would be helpful in this case though, and I will bring it up internally to see if it makes sense as a feature.

What's involved in having tests balance better across runners? Would that make sense in a separate PR?

Essentially, it is enabling Test Distribution and configuring local executors. I would recommend a separate PR though, since the change is logically different, and so we can use the data accumulated from this one to better inform how many executors to configure.

[dsmiley]

Cool; I'll merge tomorrow if I don't get any +1 sooner.

[janhoy]

Lgtm, exciting!