Use maven reactor for installing modules in mavenExecuteIntegration step#5581
Conversation
|
|
|
|
@Quaffel Thanks for the contribution. I like the approach and makes sense to me. I don't know what was the idea behind using maven "install:install-file" goal in the step but the current PR seems to overcome the previous implementation drawbacks. |
|
/it |
|
SAP employees are expected to use their SAP-email address for commits related to their work. Our compliance check has detected usage of an email other than a SAP one by a SAP employee. Please update your pull request accordingly. If you think this is wrong or need any assistance, please contact ospo@sap.com. |
Quaffel
force-pushed
the
maven-reactor-in-integration-test
branch
from
d096285 to
0d0d988
Compare
|
Sorry, I accidentally merged |
|
/it |
|
|
/it |
* origin: (70 commits) fix(artifactPrepareVersion): reduce parameter scope (SAP#5612) Use maven reactor for installing modules in `mavenExecuteIntegration` step (SAP#5581) chore(ci): Add condition to SonarQube analysis step (SAP#5611) fix: filter out GHA jobs and truncate response body on http wrappers (SAP#5609) fix(codeqlExecuteScan): buffer issue (SAP#5608) feat: extend the generate build artifact metadata for golang (SAP#5428) feat: creating kaniko build artifact metadata (SAP#5435) feat: Artifact prepare version exclusion flag (SAP#5597) ABAP Aunit Run step: Fix spelling of 'success' in test cases (SAP#5602) fix: always display debug logging with verbose: true on GitHub Actions (SAP#5601) feat: Switch order of GCS authentication (ST Token over json Key file) (SAP#5578) chore(renovate): Add ignorePaths for test data (SAP#5586) chore(renovate): migrate Renovate config (SAP#5585) chore(renovate): Add ignorePaths for integration test data (SAP#5584) chore(deps): update module github.com/stretchr/testify to v1.11.1 (SAP#5535) fix(CxOne) handling of critical and info severities in sarif generation (SAP#5582) fix(cnbBuild): Improved error handling (SAP#5577) Fix: shellExecute script download fails with query parameters in URL (SAP#5576) Revert "feat: Artifact prepare version exclusion flag" (SAP#5579) feat: Artifact prepare version exclusion flag (SAP#5565) ...
2 participants
Description
Maven handles multi-module builds through the so-called reactor mechanism (docs). Piper already makes use of that mechanism through the
-plflag in other steps.mavenBuild, for instance, uses the-plflag to exclude theintegration-testsmodule from the build.For some reason, piper does not use the same mechanism in the
mavenExecuteIntegrationstep. Instead, piper resolves thepom.xmlmanifest of theintegration-testsmodule and runs maven for that module only. The optionalinstallArtifactsoption does something similar: Rather than installing theintegration-testsmodule and its dependencies in a single go, piper runs theinstall:install-filegoal for every module individually. This is overly complex and probably dissimilar to how developers build their projects locally.It's also unclear to me why
installArtifactsonly causes theinstall:install-filegoal to be run. This goal expects that the build artifacts (e.g., jar files) are already present. The Piper general-purpose pipeline does not build the application in the scope of theintegrationstage though. Some projects seem to work around this by including a build step in theintegrationPreSteps.This pull request extends the
mavenExecuteIntegrationstep with a new option,useReactorForMultiModuleBuild(name open to discussion). When enabled, piper builds and installs the application properly using the maven reactor before running the integration tests. The integration tests are then run using the-plflag, just as themavenBuildstep does.In case the use of
install:install-fileis deliberate, I'd suggest to enhance the documentation of the step for clarification. If users are expected to configure the build themselves (throughintegrationPreSteps), I feel that the documentation should clearly tell them to do so.Checklist