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 #4230

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

erichaagdev
Copy link

This pull request connects the build to the Gradle Enterprise instance at https://ge.spring.io/. This allows the Spring Cloud Netflix 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 Cloud Netflix and all other Spring projects. On this Gradle Enterprise instance, Spring Cloud Netflix 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, Spring Security, and many other Spring projects are already connected to https://ge.spring.io/ and are benefiting from these features.

With these changes, in the best case scenario where nothing has changed between two build invocations, I saw local build times go from 1m 46s to 10s.

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. I have already configured the workflows with the proper environment variables, they just need to be added to the environment.

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.

@spencergibb
Copy link
Member

This is something I've considered but it hasn't been a high priority. If we do it, I'd like all of the maven configuration to be in spring-cloud-build so all of our projects would benefit rather than just one.

@erichaagdev
Copy link
Author

Hey @spencergibb! 👋

There has to be some changes made to each project to add the Maven extension and configure annotation processors depending on which processors are on the project classpath. The configuration in gradle-enterprise.xml could be centralized in a Spring Maven conventions extension (à la the Spring Gradle conventions plugin) but it hasn't been something we've coordinated work on yet.

Regarding spring-cloud-build, is this where the Spring Cloud configuration lives? You'll notice I updated the GitHub Actions workflows with the appropriate credentials, but if you use another CI we could centralize the credentials there.

We recently worked with the Spring Data team to connect all of their projects to ge.spring.io. The idea is to also do the same for Spring Cloud. I can connect the rest of the Spring Cloud projects once you are happy with this PR.

@erichaagdev
Copy link
Author

Hi @spencergibb. Have you given any more thought on rolling out Gradle Enterprise to Spring Cloud projects?

@spencergibb
Copy link
Member

No, we'll chat about it as a team after the new year

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.
@erichaagdev
Copy link
Author

Hi @spencergibb and Happy New Year! I just wanted to check in to make sure this is still on your team's radar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants