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

Connect build to ge.spring.io to benefit from deep build insights and faster builds #673

Closed
wants to merge 3 commits into from

Conversation

erichaagdev
Copy link
Contributor

This pull request connects the build to the Gradle Enterprise instance at https://ge.spring.io/. This allows the Spring Data Examples project to benefit from deep build insights provided by build scans and faster build speeds for all contributors as a result of local and remote build caching.

This Gradle Enterprise instance has all features and extensions enabled and is freely available for use by Spring Data Examples and all other Spring projects. On this Gradle Enterprise instance, Spring Data Examples 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

Spring Boot, Spring Framework, and Spring Security are already connected to https://ge.spring.io/ and are benefiting from these features.

Appropriate access must be configured to publish build scans. To provision a Gradle Enterprise access key for local development, you can invoke the following Maven goal:

./mvnw gradle-enterprise:provision-access-key

For instructions to connect CI to the remote build cache and to publish build scans, please follow the instructions here in Gradle Enterprise Conventions. You can disregard that this is a Gradle plugin, the instructions in the README work the same.

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

This change publishes a build scan to ge.spring.io for every local build from an authenticated Spring committer and for CI where appropriate access tokens are available. The build will not fail if publishing fails.

This change also allows the build to benefit from local and remote build caching, providing faster builds for all contributors.

Additionally, the project will have access to all features of Gradle Enterprise 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
This is done to speed up builds by avoiding recompilation of all sources when making non-ABI changes. This also optimizes the Gradle Enterprise build caching infrastructure.
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Nov 2, 2023
@mp911de mp911de added type: task A general task and removed status: waiting-for-triage An issue we've not yet triaged labels Nov 3, 2023
@mp911de
Copy link
Member

mp911de commented Nov 3, 2023

Can we selectively disable test avoidance? Spring Data examples are here to let folks run tests. By skipping tests by the extension:

[INFO] --- surefire:3.1.2:test (default-test) @ spring-data-jpa-graalvm-native ---
[INFO] Loaded from the build cache, saving 2.281s

we avoid what this project advocates for.

The purpose of this project is to showcase Spring Data features using tests. The tests should never be avoided as a result of build caching.
@erichaagdev
Copy link
Contributor Author

Thanks for the additional context @mp911de! I have pushed a commit which disables build caching for tests. In the resulting build scan we can see the cacheability status of each test task is Goal execution marked as not cacheable, yet we are still able to get some avoidance on the compilation.

@mp911de mp911de closed this in cec144e Nov 6, 2023
@mp911de
Copy link
Member

mp911de commented Nov 6, 2023

Thank you for your contribution. That's merged now.

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

Successfully merging this pull request may close these issues.

3 participants