Develocity integration

[ribafish]

As one of the impactful Eclipse projects, we (the Develocity Solutions team) would like to invite you to be a part of the Eclipse Develocity evaluation initiative.

Description

This improvement will enhance the functionality of the Eclipse SWT build by publishing a build scan for every CI build and for every local build from an authenticated Eclipse committer. The build will not fail if publishing fails. The build scans of the Eclipse SWT project are published to the Develocity instance at develocity-staging.eclipse.org, hosted by the Eclipse Foundation and run in partnership between the Eclipse and Gradle. This Develocity instance has all features and extensions enabled and is freely available for use by the Eclipse SWT project and all other Eclipse projects.

On this Develocity instance, the Eclipse SWT project will have access not only to all of the published build scans but also to other aggregate data features such as:

• Dashboards to view all historical build scans, along with performance trends over time. For example, look at the Quarkus instance trends dashboard with the ci filter applied.
• Build failure analytics for enhanced investigation and diagnosis of build failures. You can also explore the Quarkus instance for example of a different OSS projects Develocity instance.
• Test failure analytics to better understand trends and causes around slow, failing, and flaky tests. Going to the Quarkus instance again, this will probably give you a better representation of the type of data available. You can also order it by flakiness, which is a good starting point when deciding which tests need fixing the most.

This will also enable you to (optionally) use build time optimization features, such as (remote) build caching and Predictive Test Selection. In this PR, build caching is enabled, with the local cache being disabled on CI and only allowing CI to write to the remote cache, as per the general recommendations.

I ran some tests about build speed improvements when caching is configured with the following results. Here are the best-case (no code change) savings:

Invocation	Build time without cache	Build time with cache	Speedup
install -DskipTests=true	4m 13.218s	2m 0.526s	2.1x (2m 12.692s savings)
verify -Dscan.tag.failNever --fail-never --batch-mode --threads 1C -V -U -e -Pbree-libs -Papi-check -Pjavadoc -Dcompare-version-with-baselines.skip=true -Dorg.eclipse.swt.tests.junit.disable.test_isLocal=true	7m 44.118s	3m 47.287s	2.05x (3m 56.831s savings)

I also tried other configurations, more similar to what you have in Jenkins, but couldn't get tests to pass (even with test failure ignore). In order to correctly support caching, I have also disabled test failure ignore in your Jenkinsfile, so failed test runs are not cached. There are also some additional savings to be made for the surefire:test in org.eclipse.swt.tests, which is using user.home as an input, but I'm not familiar enough with how you're using that and how we could normalize the input.

Caching can be tested without setting up the Develocity credentials - simply run 2 or more builds (the first one will fill the local cache, next ones can use it).

More information can be read in the Eclipse announcement. Here is also a blog post abut Develocity from Eclipse Foundation, as well as a Develocity presentation, made in collaboration with Eclipse Foundation (and Gradle).

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.

IMPORTANT

To get scans publishing on CI, a helpdesk ticket needs to be opened in order for those credentials to be created, as explained in the initiative documentation. If this PR is merged without the credentials vault setup, your CI will not work because of the missing vault! This won't be visible in the PR builds, as they use the current Jenkins setup. To test it on CI, you will need to get the credentials set up and open run these changes from a secure context, which might be a PR in the repo, or from a trusted fork (yours for example), if that's configured.

Additionally, I would advise verifying with the EF Infra team about the Jenkinsfile secrets vault path, as I set it to eclipse.platform, seeing as it's merged in the projects view, but it's not the repository.

[akurtakov]

Despite what is written in the message "If this PR is merged without the credentials vault setup, your CI will not work because of the missing vault! This won't be visible in the PR builds, as they use the current Jenkins setup. " - this PR actually doesn't build.
I expect to see no failures as a proof that closed source product dependency will not sneak into build process of FOSS project. Even in the no errors case I would be quite reluctant to merge this PR without having clear showcase of things that couldn't be achieved without it as it's quite touchy build process which would be best for everyone to stay as obvious as possible.
If you want to persuade the topic more please showcase a real SWT build instance setup somewhere and explain more.