Releasing a tag does not publish a usable container image - decide the canonical registry and give CI credentials

[davidnmbond]

Summary

Publishing a container image from a release tag does not work. The publish-docker job in ci.yml fails at "Login to Docker Hub" with Username and password required — the repository has no DOCKERHUB_USERNAME/DOCKERHUB_TOKEN secrets. It failed on 0.2.5, the first tag the repo has ever had, so it has never worked.

Meanwhile the actual deployments pull from a private Harbor registry:

Environment	Image
Production	pdl-harbor-prod.panoramicdata.com/library/maps:0.2.0
Test	pdl-harbor-test.panoramicdata.com/library/maps:0.2.0

So there are two problems, and the second is the important one: there is no automated path from a tag to a deployable image, and a release job that always fails is a release job nobody reads.

Why this matters more than a normal CI gap

This service is a drop-in replacement for the Google Static Maps and Geocoding APIs — same query surface, same lat,lng ordering, same markers/path/size/scale descriptors — with a set of advantages that only materialise if people can actually run it:

• No per-request cost. Google bills per static map and per geocode; this bills nothing, because the tiles and the geocoding index are yours.
• No 640×480 cap. Google's free static-map size limit does not exist here: maps render at whatever resolution you ask for, up to the configured maximum, which is what makes them usable in print-quality reports.
• An infinite right to use. OpenStreetMap data under ODbL, attributed in the rendered image. No terms that can be repriced or withdrawn.
• Your data stays yours. Geocoding a customer's site addresses no longer sends them to a third party.
• Self-hostable end to end — tiles, geocoding and rendering all run in your own infrastructure, with no outbound dependency at request time.

A public image is how someone evaluates all of that in ten minutes rather than a day. Today they must clone and build.

Decisions needed

1. Which registry is canonical for releases? Docker Hub (public, matches the open-source positioning and the README's panoramicdata/maps reference) or Harbor (private, what the clusters actually pull)? Publishing to both is legitimate — public for adopters, private for our own deployment — but it should be a decision rather than an accident.
2. Where do the credentials live? A Docker Hub access token with push scope for this repository, stored as repository secrets. Harbor equally needs a robot account if CI is to push there.

Acceptance

• A pushed tag produces a pulled-and-runnable image, with the tag version and latest, on whichever registry is chosen.
• If both registries are in scope, both are published and the workflow fails loudly when either cannot be.
• docker run instructions in the README are accurate against the published image, including the tiles/geocoder configuration it needs to be useful (see the Helm chart issue for the full stack).
• The image reports its version via /health, so what is deployed can be confirmed rather than assumed (already true since /health should report the running service version #11).

Related

• Deployment of the current release to our own clusters: Panoramic Data Jira OPS-154823.
• The full-stack packaging story: the Helm chart issue.

[davidnmbond]

Scheduled as Panoramic Data Jira OPS-154924. Operations rather than the Magic Suite backlog, because the substance is a credentials-and-registry decision held by whoever owns the Docker Hub and Harbor accounts — and it is what forces the hand-built image in OPS-154823.

Kept open as this repository's own record; the OPS ticket is authoritative for scheduling and carries the three decisions: which registry is canonical, where the push credentials live and how they are scoped, and whether to delete the Docker Hub job outright if it is not wanted.