[ https://issues.apache.org/jira/browse/MBUILDCACHE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877430#comment-17877430 ]
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-2315535102 > Different plugin parameters result in different hash sums, and these different checksums are stored separately. This is only true if the plugin parameter is tracked by the effective pom. By default, it is not the case. Plus I track those parameters via the reconciliation tag. > If there are 3 different build configurations (though profiles or command line parameters) with 3 different groups, it yields 3 different cache records under different checksums. This makes different checksums equivalent to different zones. I want a `test group` step to resume where the `build` step ended. If the checksums are different between the 2, that's not possible. My CI flow is `compile -> parallel[test group 1, test group 2, test group 3]`. Each `test group` step should skip any plugin execution already performed by `compile` step. > I don't see any problem using classifiers or some other method to differentiate artifacts stored in the build. If we split build in logical parts, we must consider the case of the next plugins, which depend on the "zoned" cache records. And it must run consistently with the non-cached build. When I said `persist the build result of each test group`, I was meaning that running one of the test group again, without any code change, should skip all plugin executions. > 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)