Improve CI speed

[markushi]

📜 Description

1. Explicitly set buildSrc root project name to avoid breaking the cache, as indicated in this warning message:

Project accessors enabled, but root project name not explicitly set for 'buildSrc'. Checking out the project in different folders will impact the generated code and implicitly the buildscript classpath, breaking caching.

2. Enable recursive checkout of github submodules, moving this higher up in the cache, instead of performing the checkout as part of the build. This basically speeds-up the submodule checkout in settings.gradle, as it will no-op.

3. Enable gradle cache for setup-java. Removed in favor of gradle/actions/setup-gradle caching.

4. Move from gradle/gradle-build-action to the newer gradle/actions/setup-gradle, which offers improved caching (both dependencies and build cache), see the repo for more details

5. Enable gradle-home-cache-cleanup for every workflow

#skip-changelog

💡 Motivation and Context

Faster builds!

💚 How did you test it?

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against 833c8fb

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	372.26 ms	453.51 ms	81.25 ms
Size	1.70 MiB	2.28 MiB	590.89 KiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
b7fa26f	440.10 ms	533.98 ms	93.88 ms
6b4dd70	399.62 ms	479.08 ms	79.47 ms
3d8bd2b	379.45 ms	450.36 ms	70.90 ms
4e29063	376.38 ms	390.98 ms	14.60 ms
86f0096	368.63 ms	446.92 ms	78.29 ms
0bd723b	412.52 ms	496.65 ms	84.13 ms
d6d2b2e	463.14 ms	545.56 ms	82.42 ms
4e29063	384.14 ms	447.74 ms	63.60 ms
4e260b3	378.73 ms	454.18 ms	75.45 ms
c7e2fbc	398.35 ms	468.52 ms	70.17 ms

App size

Revision	Plain	With Sentry	Diff
b7fa26f	1.70 MiB	2.27 MiB	583.82 KiB
6b4dd70	1.70 MiB	2.27 MiB	583.82 KiB
3d8bd2b	1.72 MiB	2.29 MiB	577.53 KiB
4e29063	1.72 MiB	2.29 MiB	578.38 KiB
86f0096	1.72 MiB	2.29 MiB	576.50 KiB
0bd723b	1.72 MiB	2.29 MiB	578.09 KiB
d6d2b2e	1.72 MiB	2.27 MiB	555.05 KiB
4e29063	1.72 MiB	2.29 MiB	578.38 KiB
4e260b3	1.72 MiB	2.27 MiB	554.95 KiB
c7e2fbc	1.72 MiB	2.29 MiB	576.40 KiB

Previous results on branch: feat/faster-ci

Startup times

Revision	Plain	With Sentry	Diff
14647a7	331.69 ms	380.34 ms	48.65 ms
6e806f8	374.21 ms	445.38 ms	71.17 ms

App size

Revision	Plain	With Sentry	Diff
14647a7	1.70 MiB	2.28 MiB	590.89 KiB
6e806f8	1.70 MiB	2.28 MiB	590.89 KiB

[romtsn]

Enable recursive checkout of github submodules, moving this higher up in the cache, instead of performing the checkout as part of the build. This basically speeds-up the submodule checkout in settings.gradle, as it will no-op.

I still see the git submodule checkout in the logs, e.g. https://github.com/getsentry/sentry-java/actions/runs/8170306185/job/22336200668?pr=3245#step:5:37

Dunno if we should have an env-variable indicating that we shouldn't execute that git submodule block on CI?

[markushi]

Enable recursive checkout of github submodules, moving this higher up in the cache, instead of performing the checkout as part of the build. This basically speeds-up the submodule checkout in settings.gradle, as it will no-op.

I still see the git submodule checkout in the logs, e.g. getsentry/sentry-java/actions/runs/8170306185/job/22336200668?pr=3245#step:5:37

Dunno if we should have an env-variable indicating that we shouldn't execute that git submodule block on CI?

It looks like it takes no time:

But yes, once we have this in main, I want to double check if it actually helps once cached. CI env flag sounds like a good option!