[
https://issues.apache.org/jira/browse/MBUILDCACHE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878177#comment-17878177
]
ASF GitHub Bot commented on MBUILDCACHE-104:
--------------------------------------------
reda-alaoui commented on PR #175:
URL:
https://github.com/apache/maven-build-cache-extension/pull/175#issuecomment-2321803381
> To enhance the speed of project optimization, a traditional approach would
be to divide the project into smaller modules
> is chosen because reworking the existing mono-project is more expensive
I do not agree with these assumptions. I have another project having more
than 10 modules, where each module run its own integration tests, and the
constraints are exactly the same.
> and allow tests to run in parallel
I guess you mean inside the same reactor? This doesn't allow to distribute
the load across multiple machines. This need is maybe rare in the Maven
ecosystem, but this extension is probably heavily used by big projects needing
exactly that.
Please note that I applied all of my PRs to a forked version with the
distributed CI pipeline. It has been working correctly for almost a week, still
counting. Of course, that doesn't mean we can't do better using better concepts
or implementations.
> Allow multiple cache entries per checksum
> -----------------------------------------
>
> Key: MBUILDCACHE-104
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-104
> Project: Maven Build Cache Extension
> Issue Type: New Feature
> Reporter: Réda Housni Alaoui
> Priority: Major
> Labels: pull-request-available
>
> I have the following use case: a CI pipeline with a compile step *then*
> multiple parallelized test steps. Tests are split in 3 groups. Each test
> group execution specify the group via maven-surefire-plugin:test property
> 'groups'.
> Maven phase for compilation: process-test-classes
> Maven phase for tests: verify
> The compilation should use remote cache as much as possible and end up
> populating it.
> Each test execution should either use the populated cache ending with
> process-test-classes phase or a cache representing the result of the
> execution of the current test group (value for 'groups').
> The issue I have is that this extension can only store a single cache entry
> per input checksum. But I need to persist the build result of each test group.
> The easiest solution I can think of is having 4 cache zones. The first for
> the compile phase (the default zone), the 3 remaining for each test group.
> I need the compile phase to read/write from/to the default cache zone.
> I need each test group to read from its own cache zone then the default cache
> zone, *in this order*. At the end, it should write to its own cache zone.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
