Skip to content

Give each package its own version and release only what changed - #63

Merged
jwrosewell merged 12 commits into
rcfrom
ci/version-per-package
Nov 14, 2026
Merged

jwrosewell merged 12 commits into
rcfrom
ci/version-per-package

Conversation

@jwrosewell

@jwrosewell jwrosewell commented Nov 7, 2026 •

Copy link
Copy Markdown
Contributor

Problem

Step 3.5 of the run book in common-ci#306. ci/build-package.ps1 line 31 ran mvn versions:set in each package tree, so every one of the 45 artifacts this repository publishes to Maven Central got a new version whenever anything changed. The last release, 4.5.130 on 5 November, published all 45 at that version.

The run book's decisions are that each package has its own version, tagged <package>/<version> and continuing from the version it last published, that a package is released when a file under its folders changed since its last tag together with every package that depends on it, and that only the patch number moves.

The release #112 merged into main at 10:35 UTC on 13 November, and its Publish (run 43410313251) built all 45 at 4.5.131. Maven Central refused the upload with "Publishing blocked: your organization has reached its monthly release size limit. Grace period ended 2026-11-05. Usage resets 2026-12-01.", so nothing was published or tagged, and 4.5.130 is still the newest version of every package.

Change

  • ci/packages.json lists the 45 published modules, each named by its artifactId, with its folder, the other folders its build takes files from, and the packages it depends on. A parent's folder is its pom.xml alone, because the rest of its folder is its modules. DependsOn holds the parent and every dependency on another package in any scope, test jars included. The two on-premise engines and ip-intelligence.translation take files from the cxx submodule, and pipeline.did from pipeline/owid-java, so a change to either submodule releases them.
  • ci/release.ps1 loads common-ci's steps/release-plan.ps1, which works out the plan, as 51degrees-python#47 does. It is kept apart from ci/packages.ps1, which every script loads, so building and testing a pull request does not need the shared step. It adds what Maven needs.
    • Get-BuildPlan gives the plan, or every package at its released version when nothing changed, so the nightly publish still has packages to test.
    • Set-PomVersions writes each published module's own version into its pom.xml, with the versions of its parent and of every package it depends on. A module that is not released stays at its last release, so a released module requires what is on Maven Central. The poms in the repository keep one development version.
  • ci/build-package.ps1 sets those versions and deploys only the planned modules, with -pl, so the one publishing bundle holds only them. It passes common-ci no folder to run versions:set in. The link it made at target/central-publishing is gone, because common-ci's java/build-package.ps1 has found the bundle under any module since common-ci#274.
  • ci/build-package.ps1 also writes the size and file count of the publishing bundle into the log, because Maven Central limits each organisation's release size and file count in a calendar month.
  • ci/publish-package.ps1 uploads the bundle, then pushes the tag of every planned package in one atomic push, makes a GitHub release for each, and tells common-ci not to add its own single tag. The release notes list the commits that touched the package's files. With one push for each tag, as this branch had before 9ad8a42, a publish that stopped after its first push left the dependants untagged, and a run made again then planned nothing for them, because the plan skips a package tagged at the commit and finds dependants only from packages that changed. That is the fault found in 51degrees-php#37 and 51degrees-node#37. One atomic push leaves every package tagged or none, as in 51degrees-go#60. Its Pester 5 tests are ci/publish-package.Tests.ps1.
  • ci/get-next-package-version.ps1 gives common-ci the highest planned version as a label for the run, and ci/package-update-required.ps1 prints the plan and says whether there is anything to publish. Both are as in 51degrees-python.
  • ci/check-version-bump.ps1 and ci/check-release-interval.ps1 run common-ci's shared checks with -TagPrefix for each planned package, so each is checked against its own tags for a major or minor move and for a release less than a week after its last. They are modelled on 51degrees-dotnet's ci/check-version-bump.ps1. common-ci's nightly-publish.yml runs them, because it lists this repository in OWN_CHECK (run book step 2).
  • ci/run-integration-tests.ps1 and ci/run-performance-tests.ps1 point the examples at the version of device-detection, ip-intelligence and pipeline.jsonbuilder the publish built, in place of the one version of the run.
  • ci/build-project.ps1 fails a pull request whose poms refer to a package its DependsOn does not name, or that adds a module with no entry, because a dependent left out would not be released with the package it depends on.
  • ci/packages.ps1 calls its list of trees $Trees, which ci/update-packages.ps1 follows, so the word package means one thing. The root pom.xml, README.md, AGENTS.md and ci/README.md describe the new scheme.

No commit carries a version directive, and no major or minor number moves.

Checks at this head

The head is 48bedb3. Since the last body it has rc (6e03a25) merged in at 713256e, and 48bedb3, which gives the filter's test fixtures https://example.com links in place of three untagged 51degrees.com links that the campaign tag lint failed (run 43533248603), and adds .github/workflows/ci-script-tests.yml so the two Pester suites run on pull requests. rc now has the same workflow, byte for byte, from #43.

The head is now b2c9b9f6, which adds to ci/README.md how to make by hand the GitHub releases that a publish stopped in gh release create leaves out (the review finding of 09:51 UTC on 14 November). It changes that one file and no script, so the dry run, the tests and the full build below, which ran on its parent 48bedb3, still hold. Under the decision of 11:35 UTC on 12 November for changes that touch only CI scripts and their notes ("rebuild and include, but the change doesn't impact the code so no need to run the full builds"), it needs only its quick checks, which are green, the CI script tests (run 43582975973, both Pester suites on Ubuntu and Windows), the environment variable names check (run 43582975969), the campaign tag lint (run 43582975999) and Only rc into main (run 43582976239) on b2c9b9f.

A dry run of Publish (run 43559110241, passed). It ran common-ci's nightly-publish.yml at rc, with dryrun set, on a temporary branch holding 48bedb3 and two temporary commits, e4bf0a5 (the workflow that calls it) and 334a99c (sets PublishAnyBranch in ci/install-package.ps1, so that the Package job runs ci/publish-package.ps1 off main). The 45 first-release tags are on GitHub, so nothing else was needed.

  • Configure planned 39 packages, all from 4.5.130 to 4.5.131, with the label 4.5.131. common-ci lists this repository in OWN_CHECK, so it ran ci/check-version-bump.ps1 and ci/check-release-interval.ps1, which checked each of the 39 against its own tags. For each, the version check printed "Publishing 4.5.131, against 4.5.130 already released. The patch place, which needs no agreement.", and the weekly check printed a line such as "The last release, pipeline.core/4.5.130, was on 4 November 2026, so the next may go from 11 November 2026. This one is on 14 November 2026, so it may go." after noting that the weekly rule is not enforced while WEEKLY_RELEASES_FROM is not set.
  • 20 packages changed since 4.5.130, being pipeline.core, pipeline.did, pipeline.engines, pipeline.cloudrequestengine, pipeline.engines.fiftyone, pipeline.translation, pipeline.javascriptbuilder, pipeline.jsonbuilder, pipeline.web, pipeline.web.mvc, pipeline.geo-location, geo-location.cloud, device-detection.hash.engine.on-premise, device-detection.cloud, device-detection, ip-intelligence.shared, ip-intelligence.translation, ip-intelligence.engine.on-premise, ip-intelligence.cloud and ip-intelligence. The other 19 depend on one of them. Almost every package depends on pipeline.core, whose changes this week include the configuration schema and the Pipeline builder.
  • The 6 left at 4.5.130 are pipeline, pipeline.common, pipeline.caching, pipeline.web.packages, pipeline.developer-examples and pipeline.developerexamples.web.shared.
  • The Build job deployed the 39, and its log gives "The publishing bundle for 39 packages is 120100780 bytes (114.5 MiB) in 876 files". The seven Test jobs installed the built packages and tested the examples against them. The Package job printed "Dry run - not uploading 'central-bundle.zip' (120100780 bytes)", tagged the 39 in its own checkout, and pushed nothing.

The atomic tag push, tests first. 8a2d77e5 adds ci/publish-package.Tests.ps1, five Pester 5 tests that run ci/publish-package.ps1 with a stub upload script, a stub of common-ci's release plan, and git, gh and the plan mocked, and 199df782 holds the change. Red, run 43531268900 on tmp/java-63-pub-red2 (8a2d77e with a temporary workflow running the file with Invoke-Pester on ubuntu-latest and windows-latest), failed "pushes every tag in one atomic push" with "Expected git to be called 1 times exactly, but was called 2 times" on both systems, and passed the other four (one release for each tag, no release when the push fails, nothing pushed in a dry run, nothing pushed for an empty plan). Green, run 43531267502 on tmp/java-63-pub-green2 (199df78), passed all five on both.

The CI script tests (run 43559011191, passed) ran ci/publish-package.Tests.ps1 and ci/release-plan-filter.Tests.ps1 on 48bedb3 on Ubuntu and Windows, and the campaign tag lint passed on the head (run 43559011208).

The full pull request build (run 43559044228, passed) built 48bedb3 merged with rc (6e03a25) on nine configurations, Ubuntu x64 with Java 8, 11, 17 and 21, Ubuntu arm64 with Java 17, and Windows with Java 8, 11, 17 and 21, and every job passed. Each of its ten Setting 'PullRequestSha' lines names 48bedb3, and its Configure job printed "Left out 6 macOS entries". macOS was left out of this draft's full build under the 9 November decision. The rc head is built with macOS before it merges into main.

A trial merge with rc at ceab088, which has since taken #27, #124 and #43, was clean on 14 November at 09:30 UTC. #27 changes only description and scm in ten poms, which ci/release-plan-filter.ps1 leaves out (cases 1 and 2 of the filter's dry run below).

Checks on earlier heads

The checks ran on GitHub runners with common-ci at rc checked out at the root and this branch inside it, as common-ci's workflows lay them out. Each temporary branch was deleted when its run finished.

The run book's checks 1 to 4 (run 42368761295, passed). The workflow tagged every package locally at this branch's head, made one local commit for each case, and ran the scripts the publish runs. Nothing was pushed.

  1. A change to a package nothing depends on, one line in ip-intelligence/ip-intelligence, planned ip-intelligence 4.5.130 to 4.5.131 alone.
  2. A change to a package others depend on planned it and every package depending on it, each after the packages it depends on, which the workflow checked against DependsOn with code of its own rather than the shared functions.
    • One line in pipeline/pipeline.core planned 34 packages, pipeline.core first and geo-location.examples last.
    • One line in location/pom.xml planned the 9 packages of the location tree.
    • A new commit for the cxx submodule planned the two on-premise engines and ip-intelligence.translation as changed, and device-detection, ip-intelligence and geo-location.examples with them, 6 in all.
  3. Every planned version was the package's last tag with the patch number moved, 4.5.130 to 4.5.131, and ci/check-version-bump.ps1 passed each package against its own tags.
  4. A change to ci/options.json, a workflow, the root pom.xml, AGENTS.md, pipeline/README.md, two Doxyfiles and three files under examples/ planned nothing.

The same run also showed the following.

  • With nothing changed, the plan was empty, ci/package-update-required.ps1 exited 1, and the build plan held all 45 packages at 4.5.130 for the tests.
  • With no package tags at all, the plan stopped with pipeline has never been released and packages.json gives it no FirstVersion, so a publish before the first-release tags exist releases nothing.
  • From the first-release tags below, the next release is 29 packages at 4.5.131, the label for the run is 4.5.131, and both checks passed. pipeline.engines.fiftyone, pipeline.javascriptbuilder and pipeline.geo-location changed since 4.5.130, and the other 26 depend on them. The 16 left at 4.5.130 are pipeline, pipeline.common, pipeline.core, pipeline.did, pipeline.engines, pipeline.caching, pipeline.cloudrequestengine, pipeline.translation, pipeline.web.packages, pipeline.developer-examples and six of its eight examples.
  • Set-PomVersions wrote 4.5.131 into the 29 planned poms and 4.5.130 into the other 16, with each parent and dependency at its own package's version. pipeline.engines.fiftyone 4.5.131, for example, requires pipeline.engines 4.5.130, and pipeline.device-detection 4.5.131 manages pipeline-aggregate 4.5.131. mvn -pl <the 29> validate then read the rewritten reactor and the 29 modules at 4.5.131, BUILD SUCCESS.
  • The packages.json check found nothing missing as committed. With pipeline.core taken out of the DependsOn of pipeline.engines and the entry for geo-location.web.examples.shared removed, it named both.

A dry run of the publish, through common-ci's nightly-publish.yml at rc with dryrun set, with the first-release tags made in each job's checkout by a temporary step, and with PublishAnyBranch set so the Package job runs ci/publish-package.ps1 off main (run 42369689241). The Configure job printed the same plan of 29 packages at 4.5.131 and the label 4.5.131. With this repository not yet in $OwnCheck, it ran the shared checks against the label. The version check passed, and the weekly check dated 4.5.130 by its GitHub release, 5 November, and reported that the next may go from 12 November, as a notice because WEEKLY_RELEASES_FROM is not set. The seven Pre Build jobs built the native libraries. The Build job deployed exactly the 29 planned modules, each at 4.5.131, signed them, and the publishing plugin wrote one bundle under pipeline/pipeline.engines.fiftyone/target/central-publishing, the first planned module, which common-ci's java/build-package.ps1 found. The seven Test jobs, which install the built packages and test the examples against device-detection, ip-intelligence and pipeline.jsonbuilder at their built versions, and the Package job, which runs ci/publish-package.ps1 in dry run, all passed.

The full pull request build, common-ci's nightly-pull-request.yml run as a dry run from a temporary branch, built 70901e7, this branch's head, merged with rc (run 42423355619). All 15 build and test jobs passed, on Ubuntu x64 with Java 8, 11, 17 and 21, Ubuntu arm64 with Java 17, Windows with Java 8, 11, 17 and 21, and macOS arm64 and x64 with Java 11, 17 and 21. The first attempt failed only in MacOS_X64_Java_11, where ShareUsageTrackerTests.ShareUsageTracker_Session_DoNotTrack expected 1 and got 2, the timing failure that #61 fixes, and the second attempt of that job passed.

Documentation, tests, examples and pom metadata release nothing

James Rosewell decided on 7 November 2026 that a package is not released when the only changes under its folders since its last tag are to documentation, tests or examples, or only to metadata such as links in its manifest. common-ci#310 does that in steps/release-plan.ps1. It leaves out Markdown, LICENSE files and files under folders named docs, tests, test or examples, in any case, and then calls a repository's own ci/release-plan-filter.ps1, if it has one, with the files that are left.

Dry run

Run 42395465949 checked out common-ci at feature/release-plan-ignore (2a31d28) at the root and this branch inside it, as common-ci's workflows lay them out, ran the filter's tests and then the plan through ci/release.ps1. Every tag and commit it made was local, and nothing was pushed.

Tests Passed: 20, Failed: 0, Skipped: 0, Inconclusive: 0, NotRun: 0

From the 4.5.130 first-release tags the plan is 29 packages at 4.5.131, as before, with the reasons now counting files, such as pipeline.engines.fiftyone 4.5.130 4.5.131 changed since 4.5.130 (3 files). Each case below then started from every package tagged 4.5.131 at the branch head, which plans nothing, and added one commit.

Case Files changed Planned
1. pipeline.core pom, description and url pipeline/pipeline.core/pom.xml 0
2. pipeline parent pom, developers, licenses and scm pipeline/pom.xml 0
3. pipeline.core pom, a comment and a blank line pipeline/pipeline.core/pom.xml 0
4. pipeline.core, a file under src/test .../src/test/java/.../OptionsTest.java 0
5. pipeline.core, its README.md pipeline/pipeline.core/README.md 0
6. Cases 1, 4 and 5 together the three files 0
7. pipeline.core pom, the jar plugin's Automatic-Module-Name pipeline/pipeline.core/pom.xml 34, pipeline.core 4.5.131 4.5.132 changed since 4.5.131 (1 file) first
8. pipeline.core pom, a dependency version and the description pipeline/pipeline.core/pom.xml 34
9. pipeline.core, a source file under src/main .../src/main/java/.../BuildArg.java 34
10. Case 1 with ci/release-plan-filter.ps1 removed the pom and the filter 34

Case 10 shows that the filter, rather than the globs, is what leaves out case 1. The 34 are pipeline.core and every package that depends on it, as in the checks above.

How the 7 November decision applies

James's decision names documentation, tests, examples and metadata, so each of the following releases nothing, as the decision says.

  1. The defaults match folders inside a package's src/main too. location/geo-location.core/src/main/java/fiftyone/geolocation/core/test/MavenRunListener.java is in the published geo-location.core jar but sits in a test folder, and the main code of geo-location.examples, geo-location.web.examples.mvc, geo-location.web.examples.servlet and geo-location.web.examples.shared sits in examples folders. A change only there releases nothing, so those example packages are released only when a package they depend on is. The way to count them again is IgnoreDefaults set to false on those entries with their own Ignore list. This branch leaves the defaults on, as the decision asks.
  2. pipeline.common, pipeline.core, pipeline.engines, device-detection.shared and ip-intelligence.shared also publish a test jar built from src/test, and the examples use the device-detection.shared one. A change only under src/test no longer releases them, so their published test jars stay as they were until something else changes.
  3. Comments and layout in a pom.xml do not count. The decision named metadata such as links, and a comment changes neither the build nor what a project using the package gets.

First release

Run book step 4. Every one of the 45 packages last published 4.5.130, on 5 November 2026, from f69da52e, the commit of the plain tag 4.5.130 and the head of main today. Publish run 41934429106 built it from that commit, and Maven Central's maven-metadata.xml for each of the 45 lists 4.5.130 as its newest 4.5 version, updated at 01:03 UTC on 5 November. So each tag is <artifactId>/4.5.130 on that commit. The 45 tags were pushed on 7 November 2026, and git ls-remote --tags shows each of them on f69da52e.

git fetch origin
c=f69da52e52104687206d1ca1c3595d2935790f34
tags=
for name in \
  pipeline pipeline.common pipeline.core pipeline.did pipeline.engines \
  pipeline.caching pipeline.cloudrequestengine pipeline.engines.fiftyone \
  pipeline.translation pipeline.javascriptbuilder pipeline.jsonbuilder \
  pipeline.web.packages pipeline.web.shared pipeline.web pipeline.web.mvc \
  pipeline-aggregate pipeline.developer-examples \
  pipeline.developerexamples.web.shared pipeline.developerexamples.flowelement \
  pipeline.developerexamples.onpremiseengine pipeline.developerexamples.cloudengine \
  pipeline.developerexamples.clientsideelement \
  pipeline.developerexamples.clientsideelement.mvc \
  pipeline.developerexamples.usagesharing pipeline.developerexamples.fodid \
  pipeline.device-detection device-detection.shared \
  device-detection.hash.engine.on-premise device-detection.cloud device-detection \
  pipeline.ip-intelligence ip-intelligence.shared ip-intelligence.translation \
  ip-intelligence.engine.on-premise ip-intelligence.cloud ip-intelligence \
  pipeline.geo-location geo-location.core geo-location.cloud geo-location \
  geo-location.examples geo-location.web.examples geo-location.web.examples.mvc \
  geo-location.web.examples.servlet geo-location.web.examples.shared; do
  git tag "$name/4.5.130" "$c"
  tags="$tags $name/4.5.130"
done
git push origin $tags

The tags are lightweight, as ci/publish-package.ps1 makes them, so the weekly check dates each by its commit, 23:31 UTC on 4 November. The plain 4.5.130 tag and its GitHub release stay as they are. The scripts on main read only plain version tags, so the new tags can be pushed before this reaches main.

Maven Central

The 25 artifacts of the pipeline tree show <release>4.6.0</release> in their maven-metadata.xml, from a minor version published on 18 September 2026 and withdrawn. Their newest 4.5 version is 4.5.130, and Central kept 4.6.0 as the release when 4.5.130 was published. The plan reads only this repository's tags, so 4.6.0 does not change it, and every package continues from 4.5.130. ci/update-packages.ps1 takes patch updates only, so it does not move a requirement to 4.6.0 either. A project that asks Maven for the newest release of one of the 25, or gives a range that includes 4.6, still gets 4.6.0. Nothing here changes that.

Maven Central's publishing limits say that once an organisation's grace period has ended, "new releases that would keep the organization over that metric's limit are no longer accepted", and that "Each month starts fresh". So nothing from this repository is published before 1 December, and the size of a release decides how much of a month it uses.

  • The bundle for the 39 planned packages is 114.5 MiB (120,100,780 bytes) in 876 files (dry run above).
  • All 45 at 4.5.130 took 115.8 MiB in 972 files, by Maven Central's own listing of each version's files.
  • Three example web applications are 103 MiB of that, geo-location.web.examples.mvc (38.2 MB), pipeline.developerexamples.clientsideelement.mvc (38.2 MB) and geo-location.web.examples.servlet (32.0 MB), because each war carries Tomcat and GraalJS (js-22.0.0.2.jar alone is 16 MB). The other 36 planned packages come to about 12 MiB.

Order and what remains

  1. common-ci's steps/release-plan.ps1 with the defaults and the filter, common-ci#307 and common-ci#310, reached common-ci's main in common-ci#312 on 12 November, and its nightly-publish.yml there lists 51degrees-java in OWN_CHECK, so the publish runs this repository's own checks for each package.
  2. The 45 first-release tags are on GitHub, so nothing more is needed before the first publish from main after this merges.
  3. Each publish makes one GitHub release per package, 39 for the next release as rc stands.
  4. The dry run does not upload, so Maven Central's check of a bundle whose modules' parents are not in it, but are already on Central, has not been tried. The first real upload is on 1 December at the earliest.
  5. A publish that stops after the upload and before the push leaves Maven Central holding every planned version with no tag here. A run made again plans the same versions and fails at the upload, because Maven Central refuses a version it already has, so the tags the Package job's log names after "Pushing" are pushed by hand on the commit it published, as ci/README.md says. A gh release create that fails part way leaves tags without their GitHub release, which a run made again does not make, so those are made by hand too, and ci/README.md gives the command, with the title and notes the script uses (b2c9b9f).
  6. device-detection/Dockerfile.example sets the version from git describe --tags, which can now name a package tag. It is not used by CI and is left alone.
  7. pipeline.developer-examples with its eight examples, and the five location example modules, are published to Maven Central today, as they have been since 4.1, although their poms set maven.deploy.skip, which the publishing plugin does not read. They stay packages here, so their streams continue. Whether they should go on being published is not decided here.

Every published module is a package in ci/packages.json, named by its
artifactId and tagged <package>/<version>. A publish takes its plan from
common-ci's steps/release-plan.ps1, which releases a package when a file
under its folders changed since its last tag, and every package that
depends on it, each at its last tag with the patch number moved.

build-package.ps1 writes each module's own version into its pom.xml, with
the versions of its parent and of the packages it depends on, and deploys
only the planned modules. publish-package.ps1 tags and releases each one.
check-version-bump.ps1 and check-release-interval.ps1 check each planned
package against its own tags. build-project.ps1 fails a pull request whose
poms do not match ci/packages.json.

Step 3.5 of 51Degrees/common-ci#306.
common-ci's release plan calls ci/release-plan-filter.ps1 with the files under a package's folders that changed since its last tag, once its Ignore globs and the default globs for documentation, tests and examples have left theirs out. The filter leaves out a pom.xml whose only change is to its name, description, url, licenses, developers, scm or issueManagement, or to its comments and layout, so a new link does not release the package. A version, dependency, plugin or build change still counts, as does every other file. Its Pester tests are ci/release-plan-filter.Tests.ps1.
The example modules inside the published trees are packages of their own, but
only the files under a folder named examples were ignored, so a change to the
pom.xml, the web resources or the launcher of one released that module and
every module depending on it. Each of the fourteen now ignores its whole
folder. A release of a package an example depends on still releases the
example, as before.
@jwrosewell

Copy link
Copy Markdown
Contributor Author

Pushed 8e0c2a3, "Release nothing for a change to an example module", to this branch. Examples, tests and documentation must never cause a release, and the default ignore list only covers files under a folder named examples.

Problem

Fourteen published example modules sit outside the top-level examples/ tree. Only their files under a folder named examples were ignored. A change to a pom.xml, to src/main/webapp/** or to ExampleLauncher.java in one of them released that module and every module depending on it.

What was checked

  • Modules: pipeline/pipeline.developer-examples (the parent and eight children), location/geo-location.shell.examples, and location/geo-location.web.examples (the parent and three children).
  • Published: yes, all fourteen. Their artifacts are on Maven Central, for example https://repo1.maven.org/maven2/com/51degrees/geo-location.examples/ (4.5.130) and https://repo1.maven.org/maven2/com/51degrees/pipeline.developerexamples.flowelement/ (4.6.0), last updated 5 November. ci/build-package.ps1 deploys every module in the plan with -pl, and maven.deploy.skip in their poms does not stop them appearing.
  • So Publish: false would stop publishing artifacts that exist today. That is a decision for James, so I used Ignore instead, which keeps the artifacts published.
  • The top-level examples/device-detection and examples/ip-intelligence trees are already Publish = $false in $Trees and in no package path, so they release nothing.
  • testhelpers packages inside pipeline.common, device-detection.shared and ip-intelligence.shared are under src/main and ship in the jars, so they are not ignored.

Change

ci/packages.json gives each of the fourteen an Ignore of its whole folder (pipeline/pipeline.developer-examples/**, location/geo-location.shell.examples/**, location/geo-location.web.examples/**), and ci/packages.ps1 has a two-line comment. A release of a package an example depends on still releases the example, as before.

How it was verified

A temporary workflow ran common-ci rc's Get-ReleasePlan against a scratch history, once with this branch's previous packages.json (70901e7) and once with the new one: https://github.com/51Degrees/51degrees-java/actions/runs/42689677148 (success, 15 cases).

  • A change to an example's .jsp, ExampleLauncher.java or pom.xml (non-metadata), or to the parent pom of either example tree, released the module before (and every module depending on a parent) and releases nothing now.
  • A change to the top-level examples/ pom, a src/test file or a README.md releases nothing, before and after.
  • A change to pipeline.core source or pom, geo-location.core source, or device-detection.shared testhelpers/KeyUtils.java releases the same set as before.

(Two earlier runs, 42686586924 and 42689442767, failed because my first test edits to a pom were comments, which ci/release-plan-filter.ps1 ignores by design. Nothing in the branch changed between them.)

Builds

CI configuration only (JSON and a comment), so James's waiver of the full build for text-only changes applies and no full build was run.

Remains

Needs common-ci#312 on main first, as before.

Maven Central limits each organisation's release size and file count in a calendar month, so each publish now says how much it uploads.
A publish that stopped after its first tag push left the dependants
untagged, and a run made again then planned nothing for them, because the
release plan skips a package tagged at HEAD and finds dependants only from
packages that changed. One atomic push leaves every package tagged or none.
When gh release create fails part way, the tags are pushed and a publish
run again plans nothing, so the missing GitHub releases are made by hand
with the title and notes the script gives them.
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