Branch: refs/heads/XDOCKER-18-automate-docker-images-release Home: https://github.com/xwiki/xwiki-docker Commit: d92e3cb14e4e58bff5934e95c5e4bc5d2cb52b46 https://github.com/xwiki/xwiki-docker/commit/d92e3cb14e4e58bff5934e95c5e4bc5... Author: Vincent Massol <[email protected]> Date: 2026-08-25 (Tue, 25 Aug 2026) Changed paths: M gradle/release.gradle M gradle/run-instances.gradle Log Message: ----------- XDOCKER-18: Give each booted instance a compose project of its own * 'smokeTest' ran 'docker compose up -d' and 'down -v' straight in the version/variant directory, so its compose project was the directory basename - 'postgres-tomcat', which every cycle shares and which is also what a developer gets from 'cd 18/postgres-tomcat && docker compose up'. Booting cycle 18 while such an instance was running failed on the container name and the port 8080 already taken, and the teardown in the 'finally' then removed that instance's containers and, with '-v', its data volumes. A release check has no business deleting someone's wiki. * Rename 'runAllCompose' to 'composeInstance', move it above 'smokeTest' and use it there too, so the smoke test gets the port and container renaming plus the '-p' project that 'runAll' already had. Both derive their project name through 'composeProject', which prefixes it with the task so tearing one down never reaches the other. * Publish the smoke test on 18080 rather than 8080, so that a port a developer is already using cannot fail a boot for a reason unrelated to the image being checked. * Depend on 'generate' in 'smokeTest' and 'runAll'. The image is tagged with the model's XWiki version while the compose file names the one in the generated '.env', so './gradlew updateXWiki smokeTest' used to boot the previously published image and then wait ten minutes for a version it could never report. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Commit: a05665c1d6207b326fa031f6e1ab8e89f96bb461 https://github.com/xwiki/xwiki-docker/commit/a05665c1d6207b326fa031f6e1ab8e8... Author: Vincent Massol <[email protected]> Date: 2026-08-25 (Tue, 25 Aug 2026) Changed paths: M gradle/helpers.gradle Log Message: ----------- XDOCKER-18: Retry a download that failed rather than abort the release * 'release' streams the XWiki WAR and the LibreOffice archives, hundreds of megabytes from hosts that fail transiently often enough that the generated Dockerfile retries its own downloads for that very reason (CURL_OPTIONS in template/Dockerfile). Here a single blip aborted the run, possibly after 'versions.json' had already been rewritten for the cycles handled before it, leaving the release manager to work out how far it got. * Fold the redirect-following loop that 'httpGetText' and 'sha256OfUrl' each carried into a single 'httpGet' that hands the response stream to a consumer, and give it three attempts with a growing delay. A failure while the consumer is reading counts too, since that is where a large download dies. * Only retry what can get better on its own: an IOException and the 408/429/5xx statuses. A 404 on a version that does not exist still fails at once instead of burning the delays first. * Convert the command to plain Strings in 'stream'. ProcessBuilder only turns its list into an array when the process starts, so a GString slipped into it failed there with an ArrayStoreException rather than where it was written - and 'capture', which the same scripts use interchangeably, takes GStrings in its stride. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Commit: 35765fc4af8fec31219afbbe4f8470c8f3b02f63 https://github.com/xwiki/xwiki-docker/commit/35765fc4af8fec31219afbbe4f8470c... Author: Vincent Massol <[email protected]> Date: 2026-08-25 (Tue, 25 Aug 2026) Changed paths: M build.gradle M gradle/official-image.gradle Log Message: ----------- XDOCKER-18: Reject a cycle role that docker-library would not understand * The 'role' of a cycle is not only ours: it drives the tag aliases and the section comments of the official Docker library file that 'submitOfficialImage' submits to docker-library. A typo in 'versions.json' went through unnoticed, emitting a literal 'null' section header, silently dropping that cycle's stable-*/lts-* aliases and putting '(null)' in the Pull Request body - noticed, if at all, by a reviewer upstream. * Check the roles when build.gradle reads the model, and check that exactly one cycle is the stable one, since the branch and the commit message of that Pull Request are named after its version. * Drop the check 'submitOfficialImage' made for a missing stable cycle, now that it cannot happen, and say where the invariant comes from. * Also drop 'ext.versionsFile', which nothing read: 'writeVersions' closes over it. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Commit: 4b7d34cf141df8415643629216956d4125e80418 https://github.com/xwiki/xwiki-docker/commit/4b7d34cf141df8415643629216956d4... Author: Vincent Massol <[email protected]> Date: 2026-08-25 (Tue, 25 Aug 2026) Changed paths: M gradle/update-versions.gradle Log Message: ----------- XDOCKER-18: Hash the WAR at the URL the image downloads it from * 'updateXWiki' resolved the versions and computed the sha256 from nexus.xwiki.org while the generated Dockerfile downloads the WAR from maven.xwiki.org, on the argument that the two serve the same artifacts. They do, but pinning the bytes the image actually fetches is the whole point of the hash, and it costs nothing to read them from the one URL that matters. The JDBC and LibreOffice hashes are already taken from their own download URL. * Read the maven-metadata.xml and the WAR from maven.xwiki.org/releases, sharing the one repository URL, and read the cycle POM of 'updateJDBC' from there as well rather than from a second repository. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Commit: dca1cb0f0c3d95e389444df7b9ea2073ef22daab https://github.com/xwiki/xwiki-docker/commit/dca1cb0f0c3d95e389444df7b9ea207... Author: Vincent Massol <[email protected]> Date: 2026-08-25 (Tue, 25 Aug 2026) Changed paths: M .github/workflows/gradlew-check.yml Log Message: ----------- XDOCKER-18: Check the generated files on Pull Requests too * The Gradlew Check workflow is what guarantees that the committed generated files are what the templates and versions.json produce, but it only ran on a push to master - so a Pull Request changing either was merged before anything verified it, and master was where it broke. * Run it on Pull Requests as well. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Compare: https://github.com/xwiki/xwiki-docker/compare/3ac324f7cf4c...dca1cb0f0c3d To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-docker/settings/notifications