Skip to content

release: pre-flight guard so a SNAPSHOT-stamped artifact can't ship #54

Description

@andriishin

Context. The v1.2 release shipped readme-generator-1.2-SNAPSHOT.zip instead of readme-generator-1.2.zip, with the SNAPSHOT-stamped jar inside. The release was tagged from a commit where pom.xml still had <version>1.2-SNAPSHOT</version> (the bump-to-non-SNAPSHOT step was skipped). This broke every external GitHub Action consumer pinning nrg-version: '1.2' (and 'latest'), because nrg-action's run.sh builds the URL releases/download/v$VER/readme-generator-$VER.zip and 404'd. Three in-flight migration PRs (bludit#1706, Artalk#1124, ai-brain-tool#42) silently broke until the asset was re-uploaded manually.

Proposal. Add a pre-publish check to the release process — implemented as a small Maven-enforcer rule, a CI gate, or a release-script hardening — that:

  1. Asserts mvn help:evaluate -Dexpression=project.version does NOT contain -SNAPSHOT before the GitHub release tag/upload step runs. Fail loud.
  2. Asserts the produced asset is named readme-generator-X.Y.zip (no suffix). Could be a 1-line [[ ! \"\$ASSET\" =~ -SNAPSHOT ]] shell guard.
  3. (Optional) — after upload, smoke-test the asset URL with curl -fsLI so a 404 fails the release pipeline.

Why now. The release-process bug auto-burns external adoption. nrg-action users are first-time encounters with NRG — broken first-experience is far more expensive than the 3 minutes a guard step takes.

Already mitigated. The v1.2 asset was manually re-uploaded with a non-SNAPSHOT version stamp on 2026-05-02. This issue is for preventing recurrence on future releases.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions