Skip to content

release: pre-release detection substring-matches, misclassifying stable tags #52

Description

@pofallon

Problem

.github/workflows/release.yml decides whether a tag is a pre-release with substring matching:

if [[ "$TAG" == *"rc"* ]] || [[ "$TAG" == *"beta"* ]] || [[ "$TAG" == *"alpha"* ]] || [[ "$TAG" == *"dev"* ]]; then

Any tag containing those letters anywhere matches, not just as a version suffix. Verified:

Tag Classified Correct?
v2.2.0 stable yes
v2.2.0-rc1 prerelease yes
v2.2.0-arcadia prerelease no — "arcadia"
v2.2.0-devil prerelease no — "devil"

Why it matters more now

This was cosmetic when it only set the GitHub Release prerelease flag. The publish-image job now consumes the same flag (via the release job's is_prerelease output) to gate whether a tag moves the latest container image tag:

type=raw,value=latest,enable=${{ needs.release.outputs.is_prerelease == 'false' }}

A false-positive prerelease means a genuine stable release silently does not publish latest — and docker/compose.example.yml pins ghcr.io/get2knowio/remo-web:latest by default, so home-lab users would just never receive that release. It fails quietly: the build succeeds, version tags publish, only latest is missing.

Suggested fix

Match a PEP 440 / SemVer pre-release suffix rather than any substring, e.g.:

if [[ "$TAG" =~ -(rc|beta|alpha|dev)[0-9]*$ ]]; then

Likelihood

Low — it needs an unusual tag name. Filing because the blast radius grew when image publishing started depending on it, and the failure is silent.

Found while adding the GHCR publish job (PR #51).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions