Branch: refs/heads/XDOCKER-18-automate-docker-images-release Home: https://github.com/xwiki/xwiki-docker Commit: 4f98360bf634919b588bcd62b05d4d8e70523f98 https://github.com/xwiki/xwiki-docker/commit/4f98360bf634919b588bcd62b05d4d8... Author: Vincent Massol <[email protected]> Date: 2026-08-26 (Wed, 26 Aug 2026) Changed paths: M README.md M gradle/helpers.gradle M gradle/official-image.gradle M gradle/run-instances.gradle Log Message: ----------- XDOCKER-18: Automate updating the stable version * Default 'stream' to running in the project directory, as 'capture' and 'exitCode' already do. A process inherits the working directory of the JVM that starts it, which for a Gradle build is the daemon's and therefore not something a script gets to assume. Every command run through it passes one today, so this only ever matters for the next one written without. * Validate the '-Pcycles' and '-Pvariants' entries against the cycles and variants that exist, the way '-PbasePort' and '-PtargetRepo' already validate theirs. Both ways of getting them wrong were silent: an empty value ('-Pcycles' with nothing after it) left an empty list, which every caller reads as "no selection" and therefore as "all of them" - the opposite of narrowing anything down - and a typo such as '-Pvariants=mysql' surfaced only later as a missing directory, naming a path rather than the property that named it. The message lists the available values, which is what whoever got it wrong is looking for. * Establish the submission guards before '-PdryRun' returns rather than after it. "Am I ready to submit?" is what a dry run is reached for, and answering only "here is what the file would look like" left the release manager to discover a dirty tree, an unpushed HEAD or a red Docker Build run on the real invocation instead. A dry run reports them and still succeeds where a real one fails on them, since the natural moment to preview the file is right after './gradlew release', with the regenerated tree not yet committed. * Collect those reasons instead of throwing on the first, so that one run names everything that is in the way. 'checkImagesBuild' returns its reason rather than raising it, for the same purpose. * Check for a Pull Request still open from the working branch in a rehearsal too. Unlike the guards on what is reachable upstream, that one is about not destroying something on the target, which a target of your own has just as much of. * Say in the Docker Build check why looking at the most recent runs alone is enough for the two questions it asks. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-docker/settings/notifications