[BUILD-438] API compatibility checks may be inconsistent for reactors Created: 22/Feb/21  Updated: 07/Apr/21  Resolved: 06/Apr/21

Status: Closed
Project: Build
Component/s: Pipelines, Poms
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Mikaël Geljić Assignee: Rabie Hayoun
Resolution: Fixed Votes: 0
Labels: japicmp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Epic Link: Improve QA setup

 Description   

We currently run japicmp in a separate invocation in pipelines, through a simple mvn japicmp:cmp, i.e. we don't execute this plugin as part of any default maven phase.

Given a reactor with module A and B, B depending upon A.
A standalone invocation does not trigger a build of module A, nor does it detect previously built artifacts, therefore:

  • For a fresh version the plugin will actually fail because it cannot resolve the dependent artifact for current project version
  • For an existing version, plugin will not fail, but it will get the artifact from Nexus, which will not reflect the current build, and might show inconsistent results (builds would start failing at build n+1).

Options:

  • Recompile/repackage the whole reactor (but skip tests?) before running japicmp 
  • Attach japicmp to the regular verify lifecycle, and implement a light-weight stage on Jenkins, parsing the diff reports
  • Invoke some groovy post-analysis script (see japicmp usage)
  • Do away without japicmp on a separate stage on Jenkins


 Comments   
Comment by Mikaël Geljić [ 07/Apr/21 ]

For the record, chosen solution was:

  • Do away without japicmp on a separate stage on Jenkins pipelines

The japicmp:cmp goal is run together with mvn verify or deploy phases, so that reactor dependencies are in build context.
Standalone execution of the goal still exposes this issue.

Generated at Sun Feb 11 23:41:55 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.