Explore moving the Docker release process from Gradle to a GitHub Action

Context

The release of the XWiki Docker images is driven today by Gradle tasks run on the release manager's own machine: ./gradlew release before pushing (chaining updateXWiki, updateJDBC, updateLibreOffice, generate, generateWorkflows and smokeTest), then ./gradlew submitOfficialImage after pushing, which generates the library/xwiki file and opens the Pull Request against docker-library/official-images.

This means every release manager needs, locally: Docker running, network access to maven.xwiki.org and download.documentfoundation.org, and an authenticated gh CLI carrying the right OAuth scopes.

That last point already cost a release. During the 18.4.5 release, submitOfficialImage failed on:

Command [env -u GH_TOKEN gh repo sync <user>/official-images --source docker-library/official-images --branch master] failed (exit 1)

The release manager's token had only the scopes that gh auth login grants by default (gist, read:org, repo). Their fork of docker-library/official-images was ~30000 commits behind, so fast-forwarding it replays changes to .github/workflows/ files, and GitHub refuses that for an OAuth token without the workflow scope. Every release manager has to discover and fix this on their own machine.

Idea

Move the release steps to a GitHub Action in this repository, so the setup is done once in CI instead of once per release manager:

• a workflow_dispatch job running the pre-push part (version updates, regeneration, smoke test) and opening a Pull Request on this repository with the regenerated files;
• a second job (or a dryRun input on the same one) running the post-push part: generate library/xwiki and open the docker-library Pull Request.

Points to investigate

• Credential. GITHUB_TOKEN is scoped to this repository and cannot open a Pull Request on docker-library/official-images. A fine-grained PAT is scoped to a single resource owner and gets only public read access elsewhere, so it cannot either. This seems to require a classic PAT on a dedicated bot account, stored as a repository secret and gated behind an Environment with required reviewers, and never exposed to Pull Request triggers. Note that this repository uses no secret at all today, so this would be the first one.
• Fork. The fork used is currently the release manager's own. It would become a single bot-owned fork that the workflow keeps in sync, instead of one per person drifting until it breaks.
• Changes needed in gradle/official-image.gradle:
  • env -u GH_TOKEN is applied to every gh call because a locally set GH_TOKEN cannot create Pull Requests. In Actions gh authenticates through exactly that variable, so stripping it would unauthenticate the whole task. It has to become conditional.
  • the guard checking that HEAD is on origin/master assumes a local branch with a remote-tracking ref, which the detached checkout of actions/checkout does not provide. In a workflow triggered on master, HEAD is the pushed commit, so the guard can be satisfied differently.
  • resolving each cycle's GitCommit (git log -1 – <cycle>/) needs the full history, so fetch-depth: 0.
• Human review. Part of the value of submitOfficialImage is that a human reads the diff between the generated library/xwiki and the published one before it is submitted upstream. A workflow_dispatch with a dryRun input writing that diff to the job summary preserves that; an automatic trigger on push does not.
• Scope. Whether to move only the post-push step, or the whole release. Runners provide Docker, so smokeTest can run in CI too.
• Upstream perception. The docker-library Pull Request would be authored by a bot rather than by a committer. This is common for official images, but worth confirming.

Notes

Adding a hand-written workflow is safe: only .github/workflows/docker-build.yml is generated (from template-github/), so the Gradlew Check job will not fight a new release.yml.

Independently of this issue, the workflow scope requirement itself can be removed: gh repo sync exists only to give the next step a fresh base commit, and creating the working branch directly at the upstream tip (forks share their parent's object store) would drop that call entirely. That is a much smaller change and would unblock releases while this idea is explored.