Publish the Docker image automatically on release

[7sharp9]

Follow-up to #234, item 3 ("Releasing a docker image on publish"). Deferred out of
#234's scope by ADR-0021
(decision 4), which kept #234 focused on versioning/changelog automation.

Problem

dotnet run DockerBuild builds halcwb/genpres locally and labels it with the
<Version> from the root Directory.Build.props, but nothing publishes it. Every
release image is built and pushed by hand, so there is no guarantee that a published
tag corresponds to the commit that produced the matching CHANGELOG.md entry.

What's already in place

• Dockerfile takes an APP_VERSION build arg and writes it to
  org.opencontainers.image.version.
• DockerBuild / DockerRun FAKE targets (Build.fs), with DOCKER_IMAGE and
  DOCKER_PLATFORM overrides.
• EasyBuild.ShipIt now owns version derivation and opens the release PR
  (.github/workflows/release.yml), so there is a well-defined "a release happened"
  event to hang publishing off.

Scope to decide

• Trigger: on the release PR merging, on a git tag, or on a GitHub Release being
  published. ShipIt's behaviour on merge determines which of these actually fires.
• Registry: Docker Hub (halcwb/genpres, matching the current default) vs GHCR.
  Needs a credentials/secrets decision either way.
• Tags to push: :<version>, :latest, and whether pre-release versions
  (0.1.2-alpha.N) should move :latest at all — currently every release is a
  pre-release, so :latest semantics need settling before this is switched on.
• Multi-arch (linux/amd64 + linux/arm64) via buildx, or single-arch to start.
• Whether the published image is smoke-tested before the tag is considered good.

Constraints

• GENPRES_URL_ID and GENPRES_PASSWORD must not be baked into the image
  (see DEVELOPMENT.md § Environment Configuration) — no --build-arg for either.
  A publish workflow must not introduce them as build args by accident.
• Publishing must not block the test/format matrix in build.yml, for the same
  reason release.yml is a separate workflow.

Likely wants an ADR-0021 amendment rather than a new ADR.

[7sharp9]

Recording an answer to the "Trigger" bullet under Scope to decide, so nobody designs an on: release workflow that never fires.

Of the three candidate triggers listed — release PR merge, git tag, GitHub Release published — only release-PR-merge is available today. upstream/master has zero
git tags and zero GitHub Releases across all three shipped versions (0.1.2-alpha.2, .3, .4). EasyBuild.ShipIt in --mode pull-request bumps
Directory.Build.props, writes the CHANGELOG.md section, opens the release PR, and stops. Verified against the installed tool (3.0.1): its assembly contains no tag,
no refs/, and no releases API endpoint, so it cannot create either artifact in any mode. The github subcommand is provider-forcing, not a publish-a-Release command,
and --mode push only changes how the changelog commit reaches master.

Two further points worth having on record before this is implemented:

1. Do not copy ShipIt's documented release-job trigger. Its README suggests if: startsWith(github.event.head_commit.message, 'chore: release '). Every
   release PR here has merged as a true merge commit (chore: release GenPRES@0.1.2-alpha.2 #455 944c8d34, chore: release GenPRES@0.1.2-alpha.3 #458 5ea9b320, chore: release GenPRES@0.1.2-alpha.4 #464 9d1d017e, two parents each), so the push event's
   head_commit.message is Merge pull request #NNN from informedica/release/master, never chore: release .... That condition is 0 for 3. A merge-method-independent
   condition on the PR itself works instead:

   on:
     pull_request:
       types: [closed]
   
   jobs:
     publish:
       if: >-
         github.event.pull_request.merged == true &&
         github.event.pull_request.head.ref == 'release/master'

   ShipIt also consistently labels the PR easybuild-release:pending, which is a second usable signal.

2. If tags/Releases do get added later, GITHUB_TOKEN blocks the chain. Actions taken with the default GITHUB_TOKEN do not trigger further workflow runs, so a
   tag created that way would not fire an on: push: tags: or on: release Docker publish. Either publishing stays a downstream job of the same workflow, or the tag
   is created with a PAT / App token.

The tag-and-Release gap is being tracked separately as a follow-up to #234 item 2; if that lands first, this issue's trigger can move to the tag it creates. Until then,
release-PR-merge is the only event that does occur.

[halcwb]

@7sharp9

We should also get rid of the dotnet run DockerBuild builds halcwb/genpres, usage of halcwb.

informedica is better, but for that we need to create the proper docker account.

@jennifervdstreek is that something you could arrange?

[7sharp9]

@halcwb @jennifervdstreek Noted on the informedica Docker Hub account, I can build against that once it exists.

One alternative while that's pending is Github's: (ghcr.io/informedica/genpres) needs no new account or secret at all, it hangs off the
informedica GitHub org directly, and the workflow's own GITHUB_TOKEN could push to it with packages: write.

I could implement against GHCR now, the registry is a single build arg/target in the workflow, so repointing at Docker Hub later is a small follow-up, not a rewrite or anything major.

The following three points don't depend on which registry we pick:

1. The :latest tag will only move when we ship a stable release, not a pre-release. Every release so far has been 0.1.2-alpha.N, so :latest won't point anywhere until the first real stable version ships.
2. The image will only be built for linux/amd64 to start. That matches what DockerBuild already does today.
3. Before the workflow marks the job as passed, it will start the built image using the public demo GENPRES_URL_ID and a random throwaway password, then check that / responds with a 200. There's no dedicated health check endpoint, so / is the only thing we can check. It's not a full test, but it will catch the image failing to start, which is a good starting point.

[halcwb]

@halcwb @jennifervdstreek Noted on the informedica Docker Hub account, I can build against that once it exists.

One alternative while that's pending is Github's: (ghcr.io/informedica/genpres) needs no new account or secret at all, it hangs off the informedica GitHub org directly, and the workflow's own GITHUB_TOKEN could push to it with packages: write.

I could implement against GHCR now, the registry is a single build arg/target in the workflow, so repointing at Docker Hub later is a small follow-up, not a rewrite or anything major.

Agree, likely an official Docker Hub account for informedica (or with another name) will take some time.

The following three points don't depend on which registry we pick:

1. The :latest tag will only move when we ship a stable release, not a pre-release. Every release so far has been 0.1.2-alpha.N, so :latest won't point anywhere until the first real stable version ships.
2. The image will only be built for linux/amd64 to start. That matches what DockerBuild already does today.
3. Before the workflow marks the job as passed, it will start the built image using the public demo GENPRES_URL_ID and a random throwaway password, then check that / responds with a 200. There's no dedicated health check endpoint, so / is the only thing we can check. It's not a full test, but it will catch the image failing to start, which is a good starting point.

So, if you can implement this that would be great.