Any reason for not using semantic versioning for containers?

[davralin]

Is there any reason the containers also have a semantic versioning tag?

I see there are versioned releases, which also follow semantic versioning, so I assume there is some form of relase-process.

Could that be expanded to also create tagged containers, in addition to the normal latest-tags?

[claabs]

Mostly because this project depends on the live state of the Epic Games systems, so an old version will usually just not work. I just use semver to indicate any breaking changes in config or access pattern, or any new major features.

[davralin]

I (and many others in the k8s-at-home-community) track container updates in a monorepo with renovate, that picked up the updated digest for a new :latest-container, but didn't pick up that the release actually had a "breaking" change.

The upgrade did go just fine, but it was merely a concidence because I didn't know the app switched to a 5.0-release.

Would you accept a PR that implemented tags on a release, while still maintaining the latest tag as-is?

[claabs]

Yeah, I'd accept a PR if you're willing. Probably best to pull the version number from the package.json and tag with only the major version if that works with renovate. If not, the full semver would be fine as well. So ghcr.io/claabs/epicgames-freegames-node:5 and ghcr.io/claabs/epicgames-freegames-node:5-debian for example.

[Madic-]

Alternatively use a pinned digest image config in your kubernetes deployment.

Instead of

ghcr.io/claabs/epicgames-freegames-node:latest

use

ghcr.io/claabs/epicgames-freegames-node:latest@sha256:1a04e164fce5ca1da99dd6b6664f6ffe1bc67b5e711979bab21411eb404defa4

For more information about container digest updating with renovate see https://docs.renovatebot.com/docker/#digest-updating