[
https://issues.apache.org/jira/browse/MBUILDCACHE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876898#comment-17876898
]
ASF GitHub Bot commented on MBUILDCACHE-103:
--------------------------------------------
AlexanderAshitkin commented on code in PR #177:
URL:
https://github.com/apache/maven-build-cache-extension/pull/177#discussion_r1732057978
##########
src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java:
##########
@@ -267,6 +286,12 @@ private CacheRestorationStatus restoreProject(
// mojoExecutionScope.seed(
// org.apache.maven.api.MojoExecution.class, new
DefaultMojoExecution(cacheCandidate));
mojoExecutionRunner.run(cacheCandidate);
+ } else if
(reconciliationExecutionMojos.contains(cacheCandidate)) {
Review Comment:
I'm not convinced that this logic is valid. If you have build 1 with the
plugins [(X, parameters PX1), (Y, parameters PX1)], with the flag on the new
cached build might be a result of [(X, parameters PX2), (Y, parameters PY1)].
The issue here is that without tracking inputs/outputs, we can't guarantee that
reusing PY1 is valid if the first plugin changed parameters. It's possible that
it relies on outputs from the first plugin and could yield a different result
without the cache. This logic seems flawed to me at the moment. It might lead
to all sorts of corruptions inadvertently. it probably could run for certain
plugins in presence of additional metadata, but not in a general case.
This optimization could work for a leaf plugins (plugins which do not
contribute and do not impact subsequent plugins) but that will require an
additional plugin metadata
> Allow incremental restore in case of plugin parameter mismatch
> --------------------------------------------------------------
>
> Key: MBUILDCACHE-103
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-103
> Project: Maven Build Cache Extension
> Issue Type: Improvement
> Reporter: Réda Housni Alaoui
> Priority: Major
> Labels: pull-request-available
>
> Property {{groups}} of {{maven-surefire-plugin}} allows to run a subset of
> tests matching the property value. E.g. {{groups=foo}} will only execute
> tests tagged with 'foo'.
> If I run a build with {{groups=foo}}, and if a cache entry exists for
> {{groups=null}} (i.e. no test filter), I want the cache entry to be reused as
> much as possible and the {{maven-surefire-plugin}} to be run on top of that.
> I think I need to specify that every non null value for groups should be
> considered as a skip value.
> Following this, what I need is the ability to declare a reconcile entry in
> xml config file looking like this:
> {code:xml}
> <cache>
> <executionControl>
> <reconcile>
> <plugins>
> <plugin artifactId="maven-surefire-plugin" goal="test">
> <reconciles>
> <reconcile propertyName="groups" skipValueRegex=".+"/>
> </reconciles>
> </plugin>
> </plugins>
> </reconcile>
> </executionControl>
> </cache>
> {code}
> Could we introduce this {{skipValueRegex}} that would allow to match multiple
> skip values and fix my issue?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
