Implement tag-based deployment

[thekaveman]

After seeing #72 and the underlying issue we've been discussing in various forms, I started thinking about how this repo publishes an always moving main tag.

Related to the write-up for cal-itp/benefits#3577, there are some changes we need to make in this repo with how the image is published to accommodate version pinning.

Acceptance Criteria

• This repository requires tag-based deployment.
  • See Refactor: implement tag-based deployment benefits#2213 for more info about how this was implemented in Benefits. Here it won't be as involved since we're only concerned with publishing a Docker image to GHCR
  • Current workflow file in this repo (reacts to pushes on main)
• Tags follow our standard convention of YYYY.0M.R
• -rc tags are also supported
• A tag-based deployment (non -rc) creates a GitHub release
• The Docker image is tagged with the git tag, in addition to the commit SHA
• The label org.opencontainers.image.source pointing at the repo is added to the Docker image

[jgravois]

i like the idea of creating explicit image tags in this repo. 🤙

i can get behind calendar versioning here, but my own (humble) opinion is that semantic versioning does a better job at a glance of signaling to dependents when breaking changes are present and that an upgrade should be treated with additional caution.

[thekaveman]

my own (humble) opinion is that semantic versioning does a better job at a glance of signaling to dependents when breaking changes are present and that an upgrade should be treated with additional caution.

Fair enough. This isn't the same kind of "product" repo, so I can live with traditional semver more easily.

[jgravois]

too ambitious to target python:3.14-bookworm as our v1.0.0-rc.1?

[thekaveman]

too ambitious to target python:3.14-bookworm as our v1.0.0-rc.1?

Have we looked at 3.14 support for Django and our important (top-level) packages here and in Benefits?

[jgravois]

django 5.2 definitely supports python 3.14.

I'll check our other top-level packages here, in benefits and in eligibility-server and do some local testing if I don't encounter any blockers.

[jgravois]

requests etc. look okay too.

since slush is coming to a close i'll put a pin in my own work in this repo, but when we come back to this issue it will certainly lay the groundwork for remote clients to opt into testing a Python upgrade. 🤙