Skip to content

Let common-ci set the versions, find the bundle and collect the unit test reports - #78

Draft
ben51degrees wants to merge 1 commit into
rcfrom
ci/common-ci-does-this
Draft

ben51degrees wants to merge 1 commit into
rcfrom
ci/common-ci-does-this

Conversation

@ben51degrees

Copy link
Copy Markdown
Contributor

The problem

When this repository was put together, common-ci's Java scripts were written for one package tree with its root pom.xml as the parent of every module. Three things in ci/ worked around that:

  1. ci/build-package.ps1 ran mvn versions:set itself in each of the six trees, because common-ci set the version at the root only, where nothing reaches the trees.
  2. ci/build-package.ps1 made a link at target/central-publishing to the first publishing tree's bundle, because common-ci copied the bundle from below the root only.
  3. ci/copy-test-results.ps1 collected the Surefire reports of modules at any depth, because common-ci looked one folder down only.

common-ci's release of 3 November (common-ci#290) took in the changes that make these unnecessary: #280 gives java/build-package.ps1 a VersionPaths list, #274 makes it find the one bundle under any module, and #278 makes the three Java test helpers collect reports from any depth. Every workflow here runs common-ci from main, so this repository has had the fixes since then and kept the workarounds.

What changes

  • ci/build-package.ps1 passes the six trees from ci/packages.ps1 as -VersionPaths and lets common-ci set the version. The link is gone. common-ci's versions:set leaves pom.xml.versionsBackup files behind, as it did for the separate repositories before the move. They are in a checkout the job throws away and nothing reads them.
  • ci/run-unit-tests.ps1 calls common-ci's java/run-unit-tests.ps1, which is what the script here had copied: one Surefire run from the root, the reports of every module copied into test-results/unit without the example tests, and the JVM crash collector when the run fails. The four Maven arguments it passed before, the dev profile and the three keys, go through -ExtraArgs. The guard for a common-ci branch without the collector is gone, because main has it.
  • ci/README.md says common-ci sets the version in each tree.

What stays

ci/copy-test-results.ps1 stays for ci/run-integration-tests.ps1 and ci/run-performance-tests.ps1. common-ci's helpers copy the reports of the one Maven run they make. Those two scripts make several runs, one in pipeline and one in each examples tree against the version the publish built, and each run reports into the same folder, so they copy the reports themselves. The script's comment now gives that reason rather than the depth limit, which is fixed.

Overlap with #63

#63 rewrites ci/build-package.ps1 for a version per package and removes the same loop and link. Whichever merges second has a conflict in that file, and the resolution is to take #63's version of it. The other three files here are not touched by #63.

How it was checked

  • The three changed scripts parse with PowerShell 7.
  • Both scripts were run from a folder holding stand-ins for common-ci's java/run-unit-tests.ps1 and java/build-package.ps1 that print what they are given, against a checkout of this repository. The unit test script passed -Pdev, -DTestResourceKey, -DSuperResourceKey and -DLicenseKey and returned the stand-in's exit code. The package build passed the six tree folders as VersionPaths, and its -pl exclusion of the examples was unchanged.
  • The pull request job runs ci/run-unit-tests.ps1 for real. ci/build-package.ps1 runs in the publish workflow only, so a publish dry run is the check for it.

…test reports

common-ci's release of 3 November takes a list of folders to set the version
in, finds the Central publishing bundle under any module, and collects
Surefire reports from modules at any depth. The versions:set loop and the
link at target/central-publishing in ci/build-package.ps1 go, and
ci/run-unit-tests.ps1 calls common-ci's helper instead of copying it.

ci/copy-test-results.ps1 stays for the integration and performance tests,
which make several Maven runs that report into one folder. Its comment now
says so.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant