CI scoped build misses Quarkus extension runtime <-> deployment pairing, causing extension-descriptor failures on PRs

[tkobayas]

CI Build Failure Analysis: PR #6759

PR Summary

PR #6759 replaces root.getPaths() with root.getResolvedPaths() in AbstractDroolsAssetsProcessor.java — a one-line forward-compatibility fix for Quarkus 3.37.0.CR1 which removes getPaths() from ArchiveRootBuildItem. The method getResolvedPaths() is already available in the current Quarkus version (3.27.4).

Build Failure

All 5 CI matrix jobs fail with the same error:

[ERROR] Failed to execute goal io.quarkus:quarkus-extension-maven-plugin:3.27.4:extension-descriptor (default)
  on project drools-quarkus:
  Failed to collect dependencies of deployment artifact org.drools:drools-quarkus-deployment::jar:999-SNAPSHOT
  ...
  Could not transfer artifact org.drools:drools-quarkus-deployment:pom:999-SNAPSHOT
  from/to block-apache-snapshots: Blocked mirror for repositories: [apache.snapshots]

The same error occurs for drools-quarkus-ruleunits-deployment.

Root Cause

The issue is in script/ci/CiComputeBuildScopes.java, not in the PR's code change itself.

How the CI scoped build works

1. ci.yaml collects changed files from the PR diff
2. CiComputeBuildScopes.java maps changed files to Maven modules, builds a dependency graph via dep-graph-extractor, and computes three sets:
   • changed: modules whose files were modified (1 module: drools-quarkus-util-deployment)
   • affected: changed + transitive downstream dependents (12 modules)
   • upstream: transitive upstream dependencies of affected, minus affected (63 modules)
3. Two Maven passes run:
   • Upstream pass: mvn install -DskipTests -pl <upstream> (build dependencies without testing)
   • Affected pass: mvn install -pl <affected> (build and test affected modules)

The blind spot: Quarkus runtime ↔ deployment pairing

Quarkus extensions consist of two paired modules:

Runtime module	Deployment module
drools-quarkus	drools-quarkus-deployment
drools-quarkus-ruleunits	drools-quarkus-ruleunits-deployment

The runtime module does not declare a Maven <dependency> on its deployment counterpart. Instead, the link is declared in metadata (quarkus-extension.yaml or plugin configuration). The quarkus-extension-maven-plugin:extension-descriptor goal on the runtime module resolves the deployment artifact at build time through this metadata — outside of Maven's dependency graph.

CiComputeBuildScopes.java builds its dependency graph from Maven <dependency> relationships only. It does not see the implicit Quarkus runtime↔deployment link.

What happens with this PR

Changed file: drools-quarkus-util-deployment/src/.../AbstractDroolsAssetsProcessor.java

Dependency chain (Maven <dependency>):
  drools-quarkus-util-deployment
    ← drools-quarkus-deployment (depends on util-deployment)
    ← drools-quarkus-ruleunits-deployment (depends on drools-quarkus-deployment)

Implicit link (Quarkus extension metadata, NOT Maven <dependency>):
  drools-quarkus ←--→ drools-quarkus-deployment
  drools-quarkus-ruleunits ←--→ drools-quarkus-ruleunits-deployment

The CI places the runtime modules (drools-quarkus, drools-quarkus-ruleunits) in the upstream set because they are upstream dependencies of other affected modules (e.g., integration tests). The deployment modules (drools-quarkus-deployment, drools-quarkus-ruleunits-deployment) end up in the affected set as downstream dependents of the changed module.

The upstream pass runs first and builds the runtime modules. When Maven executes extension-descriptor on drools-quarkus, it tries to resolve drools-quarkus-deployment. But:

• drools-quarkus-deployment is not in the upstream reactor (it's in the affected set, built later)
• It is not in ~/.m2 (it's a 999-SNAPSHOT that was never published)
• The apache.snapshots repository is blocked by settings.xml in CI

Result: resolution failure.

Possible Fixes

Option A: Pair runtime and deployment modules in CiComputeBuildScopes.java

Add logic to detect Quarkus extension modules (e.g., by convention: if <artifactId>-deployment exists in the reactor, treat them as paired). When either half is in the affected/upstream set, include the other half in the same set.

Option B: Add -amd (also-make-dependents) awareness for Quarkus metadata

Extend dep-graph-extractor to parse quarkus-extension.yaml or META-INF/quarkus-extension.properties and inject synthetic dependency edges between runtime and deployment modules.

Option C: Convention-based fix in ci.yaml

After computing the build scope, add a shell step that scans for Quarkus extension modules and ensures both halves are in the same build pass.

[yesamer]

@tiagobento ^^

[yesamer]

@tkobayas I restared them, mac-os build are now green, still failing for windows and ubuntu. 😕

[tkobayas]

@yesamer Thanks, so the issue looks intermittent. The analysis doesn't explain the intermittent nature, so it may be wrong. I will try to reproduce the issue later.

Still, the PR is fine to merge, I think.