[ISSUE #4688] Capture build scans on ge.apache.org to benefit from deep build insights

[clayburn]

Closes #4688.

Motivation

This PR publishes a build scan for every CI build on 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 EventMesh project will be published to the Develocity instance at ge.apache.org, hosted by the Apache Software Foundation and run in partnership between the ASF and Gradle. This Develocity instance has all features and extensions enabled and is freely available for use by the Apache EventMesh project and all other Apache projects. Currently, this is being used by other ASF projects such as Beam, Kafka, Solr, and more.

On this Develocity instance, Apache EventMesh 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

To see an example of the insights, see this Build Scan. 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.

Modifications

• Added the Gradle Enterprise and Common Custom User Data Gradle Plugins
• Configured the Gradle Enterprise Gradle Plugin to publish Build Scans to ge.apache.org

Documentation

• Does this pull request introduce a new feature? (no)

[github-actions]

Welcome to the Apache EventMesh community!!
This is your first PR in our project. We're very excited to have you onboard contributing. Your contributions are greatly appreciated!

Please make sure that the changes are covered by tests.
We will be here shortly.
Let us know if you need any help!

Want to get closer to the community?

WeChat Assistant	WeChat Public Account	Slack
		Join Slack Chat

Mailing Lists:

Name	Description	Subscribe	Unsubscribe	Archive
Users	User support and questions mailing list	Subscribe	Unsubscribe	Mail Archives
Development	Development related discussions	Subscribe	Unsubscribe	Mail Archives
Commits	All commits to repositories	Subscribe	Unsubscribe	Mail Archives
Issues	Issues or PRs comments and reviews	Subscribe	Unsubscribe	Mail Archives

[pandaapo]

Thank you for your PR!

Could you please explain the differences or advantages between the build scan in this PR and the GitHub Actions build scan currently used in the project? (My understanding is that this is not to replace various types of CI, but rather mainly to aggregate, analyze, and visualize the data of CI. Is that so?)

Why can't I find the build scan for this CI?
https://ge.solutions-team.gradle.com/scans?search.rootProjectNames=eventmesh&search.timeZoneId=Asia%2FShanghai
https://ge.apache.org/scans?search.rootProjectNames=eventmesh&search.timeZoneId=Asia%2FShanghai

May I ask what is the difference between these two services?
https://ge.solutions-team.gradle.com/
https://ge.apache.org/

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (1a381ed) 17.39% compared to head (bcbdfaf) 17.40%.

Additional details and impacted files

@@            Coverage Diff            @@
##             master    #4685   +/-   ##
=========================================
  Coverage     17.39%   17.40%           
- Complexity     1759     1760    +1     
=========================================
  Files           797      797           
  Lines         29850    29850           
  Branches       2579     2579           
=========================================
+ Hits           5192     5194    +2     
+ Misses        24177    24176    -1     
+ Partials        481      480    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Pil0tXia]

@clayburn Welcome to EventMesh community!

The compilation speed of Gradle Enterprise is faster than GitHub Actions, which is an advantage. I have a few questions:

1. How can reviewers intuitively view the build results of Gradle Enterprise on the PR page, similar to GitHub Actions? This is important for reviewers.
2. Contributors need to use the Console Log page to see the reasons for build errors. Currently, the provided Build Scan requires manual paging to view the logs, which is inconvenient. GitHub Actions can automatically navigate to the error location and quickly scroll up and down to view the logs. I believe that the way GitHub Actions allows for viewing logs is more powerful. I hope that Gradle Enterprise can also provide a similar log viewing experience.
3. Currently, in the EventMesh community, CIs need to be manually triggered by reviewers before the PR is approved, which is inconvenient. With Gradle Enterprise, is it possible to automatically trigger the CI of a PR without manual approval by reviewers?
4. There are many projects under Apache, why have you only submitted a PR related to Gradle Enterprise for the EventMesh project at the moment?

---

Regarding the difference between ge.apache.org and ge.solutions-team.gradle.com mentioned by @pandaapo, I think that the CI test results on ge.solutions-team.gradle.com are examples provided by Gradle Enterprise. Once the EventMesh community accepts the PR, the build results will appear on ge.apache.org.

[clayburn]

@pandaapo:

Could you please explain the differences or advantages between the build scan in this PR and the GitHub Actions build scan currently used in the project? (My understanding is that this is not to replace various types of CI, but rather mainly to aggregate, analyze, and visualize the data of CI. Is that so?)

The build scan will go much more in depth into what was happening during the Gradle portion of your GitHub Actions workflow. GitHub Actions is mostly limited to console log viewing at this point in time, so the build scan can provide much more insights into task execution, test results, performance, etc.

You are correct that it is not to replace CI, but to give deeper insights into the Gradle build itself.

Why can't I find the build scan for this CI? https://ge.solutions-team.gradle.com/scans?search.rootProjectNames=eventmesh&search.timeZoneId=Asia%2FShanghai https://ge.apache.org/scans?search.rootProjectNames=eventmesh&search.timeZoneId=Asia%2FShanghai

You cannot see build scans from this PR because GitHub Actions does not allow builds from forks to access secrets. So, because this build did not access the GE_ACCESS_TOKEN secret, it was not authenticated, so it did not publish a build scan.

May I ask what is the difference between these two services? https://ge.solutions-team.gradle.com/ https://ge.apache.org/

Essentially, what @Pil0tXia said is correct. The gradle.com instance is one that my team here at Gradle use. I published build scans to this instance for demonstration purposes only, because I am not a user on ge.apache.org. ge.apache.org is managed by the ASF infra team for use by ASF projects. This PR would enable sending build scans there.

@Pil0tXia:

How can reviewers intuitively view the build results of Gradle Enterprise on the PR page, similar to GitHub Actions? This is important for reviewers.

Not directly from the PR page, but we make it easier to find build scans via our gradle-build-action. Among other features, this action can create a Job Summary on the action itself. See here for an example from the AndroidX project (which may require scrolling down). I did not include that change in the PR for simplicity, but we'd be glad to add that action in a follow-up PR. It also has some caching features that can be used.

Short of that action, the link to the build scan is printed at the end of the Gradle build.

Contributors need to use the Console Log page to see the reasons for build errors. Currently, the provided Build Scan requires manual paging to view the logs, which is inconvenient. GitHub Actions can automatically navigate to the error location and quickly scroll up and down to view the logs. I believe that the way GitHub Actions allows for viewing logs is more powerful. I hope that Gradle Enterprise can also provide a similar log viewing experience.

Thanks for the feedback. Using the console log in GitHub Actions and using the build scan can be complementary when investigating build failures. When using build scans, the goal is for the console log to be something of a last resort. Build and test failures are called out more prominently in the build scan. For example, see a build failure and a test failure from the beam project.

Currently, in the EventMesh community, CIs need to be manually triggered by reviewers before the PR is approved, which is inconvenient. With Gradle Enterprise, is it possible to automatically trigger the CI of a PR without manual approval by reviewers?

Because Gradle Enterprise is complimentary to GitHub Actions, there is nothing that it provides that helps you with this problem. Gradle Enterprise will not start builds for you.

There are many projects under Apache, why have you only submitted a PR related to Gradle Enterprise for the EventMesh project at the moment?

We have already onboarded a number of projects. I listed some of them in the PR. We are just slowly working through the ASF and offering this manually to projects, doing due diligence that the change does not cause any bad side effects.

[pandaapo]

@clayburn
Can the code you added be moved to build.gradle? If possible, would it be better to write them in settings.gradle?

Additionally, could you please create a corresponding issue for this PR and link them?

@xwm1992 I think we can try introducing this feature. What do you think?

[tylerbertrand]

Hi there, @clayburn is on break for the holidays, so I'll be helping out until he is back. com.gradle.enterprise and com.gradle.common-custom-user-data-gradle-plugin are settings plugins, so they need to be applied in settings.gradle.

Additionally, could you please create a corresponding issue for this PR and link them?

Sure. I created an issue here, but it doesn't look like I have permission link this PR to the issue myself.

[pandaapo]

it doesn't look like I have permission link this PR to the issue myself.

It's OK now.

[Pil0tXia]

@clayburn Thank you for your explanation! It will be good if we can get the Build Scan link corresponding to the PR and the original build functionality remain unaffected.

[tylerbertrand]

Hey @Pil0tXia

It will be good if we can get the Build Scan link corresponding to the PR

If you are referring to the fact that build scans cannot be published for PRs from forks, at the moment there is not much that can be done about this limitation, because the secret required for publishing the scans is not available to forks. We are, however, working on a workaround for this, so it should be possible in the future.

For PRs that can publish build scans, the links will be available in the logs for individual GitHub Actions jobs. As @clayburn mentioned, we'd be happy to add the gradle-build-action in a follow-on PR, which can add a convenient summary surfacing these build scan links to the workflow summary.

In any case, the original build functionality will remain unaffected.

[Pil0tXia]

Hi @tylerbertrand

the secret required for publishing the scans is not available to forks

For forked repositories with GitHub Actions enabled, after triggering CI, Gradle Enterprise cannot access the Apache repository key. Will this result in CI failure?

Moreover, has the GE key been set up in our repository? Is there a need for additional application?

add a convenient summary surfacing these build scan links to the workflow summary.

Yes, we would like to display the Build Scan link in the PR.

[tylerbertrand]

For forked repositories with GitHub Actions enabled, after triggering CI, Gradle Enterprise cannot access the Apache repository key. Will this result in CI failure?

It won't result in a CI failure. The use of publishIfAuthenticated() in the configuration ensures that the plugin will only attempt to publish the scan if authentication is successful. Additionally, any potential build scan error, like failure to publish, or failure to authenticate, will not fail the build.

Moreover, has the GE key been set up in our repository? Is there a need for additional application?

This is a good question. GE_ACCESS_TOKEN may already be available in your repository as an organization-level secret under the Apache org. If not, you may need to reach out to the Apache infra team to get an access token and create the secret.

Yes, we would like to display the Build Scan link in the PR.

Unfortunately, the gradle-build-action won't be able to create the build scan links summary directly in the PR page. It will be created in the individual action page, for example, here is the Gradle Builds shown for an AndroidX GitHub Actions workflow execution.

[Pil0tXia]

It will be created in the individual action page

At the bottom of the PR page is a summary of the GitHub Actions results after the CI has been triggered by reviewers.

After the gradle-build-action is introduced, the example Actions page you provided can be found at the bottom of the PR page, is that right?

[runningcode]

After the gradle-build-action is introduced, the example Actions page you provided can be found at the bottom of the PR page, is that right?

Correct

[Pil0tXia]

@clayburn @tylerbertrand @runningcode Looking forward to the PR introducing gradle-build-action after this PR is merged.

[pandaapo]

@clayburn @tylerbertrand @runningcode ,

When I saw the build scan links in the CI log after PR #4696 was merged into the origin repository, I had a new question.

The CI process before the PR is merged cannot publish build scans because PR is mostly from forks, such as the CI of PR #4696 before being merged.
"gradle-build-action can add a convenient summary surfacing these build scan links to the workflow summary", the workflow summary here refers to the CI after the PR is merged into the origin repository, rather than the CI before the PR is merged. Is that right?

[clayburn]

@pandaapo - gradle-build-action only add the summary for workflows which published build scans, which as you've correctly noted, will not include unauthenticated builds from forks. If, for example, an ASF committer generated an access key from their own account and made it available to their forked repo as a secret, then the action would generate the summary.

We are working on methods to handle publishing build scans from forks in a way that does not expose the access key to those forks, but we are not ready to use it yet. Once we are, we can follow up with that improvement to give you more data.