Publish Docker image from Create Release workflow

[offtherailz]

Description

Ports the Jenkins MapStore2 Stable Releaser Docker job into the Create Release GitHub Action (.github/workflows/create_release.yml), so the release Docker image is built and pushed to Docker Hub (geosolutionsit/mapstore2) directly from the release workflow instead of a separate Jenkins pipeline.

The new docker job reuses the mapstore.war already produced by the existing build job (no second build), then builds and pushes the image, replicating the Jenkins step:

• Dockerfile at repo root, context ., --no-cache
• build arg MAPSTORE_WEBAPP_SRC=./product/target/mapstore.war
• tags geosolutionsit/mapstore2:<version> and (optionally) :latest

An input dockerTagLatest (default true) controls whether latest is also pushed — the Jenkins job always pushed latest; this lets us disable it for patch releases of older stable branches so they don't overwrite latest.

The Docker image entry in the generated release notes now shows the docker pull geosolutionsit/mapstore2:<version> command instead of the manual TODO (a tags/search URL is avoided on purpose: its prefix match would expose the internal -stable tag).

Please check if the PR fulfills these requirements

• The commit message follows our guidelines: https://github.com/geosolutions-it/MapStore2/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (check one with "x", remove the others)

• CI related changes

Issue

What is the current behavior?

The release Docker image (geosolutionsit/mapstore2) is built and published by a separate Jenkins job (MapStore2 Stable Releaser), decoupled from the GitHub Create Release workflow. The release notes contain a manual TODO placeholder for the Docker image link.

What is the new behavior?

Create Release builds and pushes the Docker image itself, in a docker job that runs after build and reuses the built war. The release notes link directly to the Docker Hub tag.

Breaking change

Does this PR introduce a breaking change? (check one with "x", remove the other)

• No

Other useful information

One-time configuration required before the next release

Add two repository secrets (Settings → Secrets and variables → Actions):

Secret	Value
DOCKERHUB_USERNAME	Docker Hub user with push rights on geosolutionsit/mapstore2
DOCKERHUB_TOKEN	Docker Hub access token (scope: read/write on that repo)

These replace the Jenkins config.json file credential (d12a6af3-…).

Running the release with Docker publish

1. Run the Create Release workflow (as today) from the stable branch.
2. version / previousVersion as usual.
3. dockerTagLatest:
   • true (default) for the newest release → also updates :latest.
   • false for a patch on an older branch → publishes only :<version>, leaves :latest untouched.

Not ported from Jenkins (intentional)

• Final docker rmi / docker image prune cleanup — GitHub runners are ephemeral.
• Downstream MapStore2-Stable-Releaser-EndPointTests trigger — out of scope of image publishing.
• The war is reused from the build job artifact instead of being rebuilt inside the docker step.

[offtherailz]

Test plan (before / after merge)

Prerequisite (blocking)

Configure the two repository secrets on geosolutions-it/MapStore2 (Settings → Secrets and variables → Actions), otherwise the push step fails:

• DOCKERHUB_USERNAME — Docker Hub user with push rights on geosolutionsit/mapstore2
• DOCKERHUB_TOKEN — Docker Hub access token (read/write on that repo)

Safe end-to-end test

Runs the real Create Release workflow with a throwaway version, publishes only the versioned tag (never latest), then removes everything.

⚠️ workflow_dispatch inputs are validated against the workflow file on the default branch (master). Until this PR is merged, master does not know the new dockerTagLatest input, so passing it may fail with "Unexpected inputs". For the pre-merge test we therefore use a dedicated test branch where the docker tags are hardcoded to the version only (no latest), and pass only version / previousVersion.

1. Create a test branch off this PR branch and hardcode the docker job tags to only geosolutionsit/mapstore2:<test-version> (drop the latest logic for the test).
2. Use an obviously fake version, e.g. 2999.12.99.
3. Trigger:

   gh workflow run create_release.yml --ref test-docker-release \
     -f version=2999.12.99 -f previousVersion=2026.01.01
   

4. Verify:
   • image geosolutionsit/mapstore2:2999.12.99 exists on Docker Hub, latest untouched
   • draft release v2999.12.99 created with the war / binary / printing assets
   • git tag v2999.12.99 created

Cleanup

• gh release delete v2999.12.99 --cleanup-tag --yes (draft release + git tag)
• delete the 2999.12.99 tag on Docker Hub (UI or registry API)
• git push origin --delete test-docker-release

After merge

Once merged, the dockerTagLatest input is available in the normal Create Release dispatch UI; set it to false for patch releases of older stable branches so they don't overwrite latest.