feat: Add release workflow

[gcgoncalves]

No description provided.

[marekdano]

Severity	File	Summary
🟠 Medium	.github/workflows/docker-release.yml:16	Tag trigger allows non-semver tags that break image tagging
🟡 Low-Medium	.husky/pre-commit (+3 sibling files)	Unrelated/broken Husky hook files committed
🟡 Low-Medium	Dockerfile:19	No fallback if Red Hat registry is unreachable during release build

---

1. Tag trigger allows non-semver tags that break tagging — 🟠 Medium

File: .github/workflows/docker-release.yml:16

The tag trigger v* is broader than the type=semver patterns used to derive image tags, so non-strict-semver tags produce no usable tags.

Failure scenario: A maintainer pushes a tag like v1.2, v1, or v2.0.0.1 — all match the tags: ["v*"] trigger, but docker/metadata-action's type=semver patterns silently produce no derived tags for a ref that isn't strict
semver. steps.meta.outputs.tags ends up empty, and the push step errors out or behaves unexpectedly instead of failing fast with a clear message.

Why Medium: Breaks the release pipeline rather than the app itself, and is easy to trigger by accident with a slightly malformed tag.

---

2. Unrelated/broken Husky hook files committed — 🟡 Low-Medium

File: .husky/pre-commit (also post-checkout, post-commit, post-merge)

Four Husky git-hook shim files were committed even though the repo has no husky devDependency or prepare script to generate .husky/_/*.

Failure scenario: These files reference .husky/_/<hook>, a directory never created in this repo. They look unrelated to the PR's stated purpose (adding a release workflow) and appear to be accidental inclusion from a local git add -A. On a machine where core.hooksPath already points at .husky (e.g. from another local husky project), every git operation would try to source the nonexistent shim and fail.

Why Low-Medium: Likely doesn't affect CI, but is scope creep/accidental commit that could break local dev workflows for some contributors.

---

3. No fallback if Red Hat registry is unreachable — 🟡 Low-Medium

File: Dockerfile:19

NODEJS_IMAGE is pinned only by digest to registry.access.redhat.com, with no automatic mirror/fallback — just a manual-override comment.

Failure scenario: If registry.access.redhat.com has an outage, throttles CI IPs, or the digest is pruned during a tagged push, the new release workflow's build step fails outright with no automatic fallback — releases are blocked until
someone notices and manually re-runs with a --build-arg NODEJS_IMAGE=<mirror> override.

Why Low-Medium: Operational risk, not a correctness bug — low likelihood but real blast radius (blocks all releases) when it hits.

[marekdano]

Looks good now!

LGTM 🚀

[vishu-bh]

LGTM 🚀