[
https://issues.apache.org/jira/browse/JAMES-3978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813731#comment-17813731
]
Jean Helou commented on JAMES-3978:
-----------------------------------
benchmark for the first naive approach
mvn clean
build cache disabled `mvn package -pl :james-server-core -T1C -am`
initial build 04:21 min https://ge.apache.org/s/6hubxpg4cnt3y
repeat build no file changes 03:34 min https://ge.apache.org/s/oqqk7t2tv6d7s
mvn clean
build cache enabled `mvn package -pl :james-server-core -T1C -am`
initial build 04:00 min [https://ge.apache.org/s/gcqnpsbcspwd2]
repeat build 03:39 min [https://ge.apache.org/s/jsnkbznbpewvu]
at this stage the build cache doesn't bring much gains. Actually this is normal
because clean *must* be included in the lifecycle for the cache to store new
entries.
playing this again with `mvn clean package -pl :james-server-core -T1C -am`
and caching enabled
initial build 04:14 min [https://ge.apache.org/s/3fk33vwguv2za]
repeat build 01:19 min
[https://ge.apache.org/s/iha526ra7enfq|https://ge.apache.org/s/jsnkbznbpewvu]
the remaining time is from mojos for which the extension has no embedded
configuration
develocity allows us to investigate the build performance to know which goals
have not been cached
!image-2024-02-02-16-30-20-026.png!
and list them easily
!image-2024-02-02-16-31-24-883.png!
as you can see a the scala compilation and style checking is not cached
> Investigate using develocity to improve james build
> ---------------------------------------------------
>
> Key: JAMES-3978
> URL: https://issues.apache.org/jira/browse/JAMES-3978
> Project: James Server
> Issue Type: Improvement
> Components: Build System
> Reporter: Jean Helou
> Priority: Major
> Attachments: image-2024-02-02-16-30-20-026.png,
> image-2024-02-02-16-31-24-883.png
>
>
> Hello,
> A while ago I noticed [this
> announcement|https://news.apache.org/foundation/entry/the-apache-software-foundation-announces-gradle-as-a-platinum-targeted-sponsor]
> gradle becoming a platinum sponsor of the ASF.
> In particular the announcement was about gradle offering the develocity
> service to the ASF. It so happens that I investigated develocity as part of
> my day job, and while we can't afford it there it is definitely something we
> might leverage here !
> The tool is available at https://ge.apache.org
> I want to investigate the following leads
>
> # local caching for builds enable reuse of tasks output to speed up repeated
> tasks
> # build scans to provide detailed build reports and individual build metrics
> # build metrics are collected across all build scans and allow to target
> objectively bad contributors to overall build time
> # enabling the remote build cache
> ** additionally improves both local and CI build times
> ** requires some attention to read/write permissions to avoid cache
> poisoning and supply chain attacks
> ** most likely requires a dedicated build cache node request to infra
> ** several projects already use it so it is a known unknown ( we know it can
> be done we don't yet know how)
> # leverage advanced test features of develocity unknown unknowns at least
> for me:D
> ## the tool collects tests metrics to pinpoint flaky tests enabling targeted
> fix efforts
> ## the tool claims to be able to do test avoidance and not rerun tests that
> are irrelevant to the changes
> ## the tool claims to be able to distribute test excecution accross
> dedicated test workers
> Since we use maven, we won't get the full benefits of the build cache (
> gradle has been pushing plugin authors to write build cache friendly code for
> a long time ) but it should improve the current situation quite a bit.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
