Pre-releases should not ovewrite existings versions

[matheusfillipe]

Summary by CodeRabbit

• Chores
  • Updated internal release automation workflow for improved version tag handling in build processes. No user-visible changes.

[coderabbitai]

📝 Walkthrough

Walkthrough

The publish workflow is modified to compute tag_name dynamically in the collect-version job. For tag-triggered builds, it prefixes the version with 'v'; for other builds, it increments the patch version and appends '-pre'. Downstream publish steps now consume this computed tag_name output.

Changes

Cohort / File(s)	Summary
Publish Workflow Versioning .github/workflows/publish.yaml	Modified tag_name computation logic in collect-version job: tag releases use v format, while non-tag builds generate v..<NEXT_PATCH>-pre versioning with branching based on GITHUB_REF_TYPE.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Possibly related PRs

• feat/release android app in actions #119: Modifies the same publish.yaml workflow's tag_name and versioning logic used by downstream publish steps.

Poem

🐰 Hop, hop, through the version tree,
Tag or pre-release, let it be!
Dynamic naming, patch bumped high,
Publish workflows reaching for the sky! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title references pre-releases and version overwriting, which directly relates to the core change: preventing pre-releases from overwriting existing versions through updated tag naming logic.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/prerelease-workflow-versioning

Tip

Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

Preview URL: https://fix-prerelease-workflow-vers.obsidianirc.pages.dev

Automated deployment preview for the PR in the Cloudflare Pages.

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/publish.yaml:
- Around line 39-41: The prerelease tag generation uses a static suffix and can
be overwritten; update the echo that sets tag_name to include a unique per-run
identifier (for example append GITHUB_RUN_ID or a short GITHUB_SHA) so each
pre-release is unique; specifically change the echo that writes tag_name
(currently creating v${MAJOR}.${MINOR}.${NEXT_PATCH}-pre) to include the run id
or commit hash (e.g. v${MAJOR}.${MINOR}.${NEXT_PATCH}-pre-${GITHUB_RUN_ID} or
v${MAJOR}.${MINOR}.${NEXT_PATCH}-pre-${GITHUB_SHA::7}) so prereleases are not
clobbered.
- Around line 36-37: Replace deriving tag_name from package.json with the actual
Git tag that triggered the workflow: when checking if GITHUB_REF_TYPE equals
"tag" (the if block containing the echo), set tag_name using the GITHUB_REF_NAME
environment variable instead of v$VERSION — i.e. emit tag_name based on
$GITHUB_REF_NAME so the publish uses the exact tag that triggered the run.

---

ℹ️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between bb8f7ee and b6879d6.

📒 Files selected for processing (1)

• .github/workflows/publish.yaml

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Use the triggering Git tag directly for tag builds.

For tag-triggered runs, deriving tag_name from package.json can mismatch the pushed tag and publish under the wrong tag/release. Use GITHUB_REF_NAME here.

Suggested fix

-          if [ "$GITHUB_REF_TYPE" = "tag" ]; then
-            echo "tag_name=v$VERSION" >> "$GITHUB_OUTPUT"
+          if [ "$GITHUB_REF_TYPE" = "tag" ]; then
+            echo "tag_name=$GITHUB_REF_NAME" >> "$GITHUB_OUTPUT"

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	if [ "$GITHUB_REF_TYPE" = "tag" ]; then
	echo "tag_name=v$VERSION" >> "$GITHUB_OUTPUT"
	if [ "$GITHUB_REF_TYPE" = "tag" ]; then
	echo "tag_name=$GITHUB_REF_NAME" >> "$GITHUB_OUTPUT"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/publish.yaml around lines 36 - 37, Replace deriving
tag_name from package.json with the actual Git tag that triggered the workflow:
when checking if GITHUB_REF_TYPE equals "tag" (the if block containing the
echo), set tag_name using the GITHUB_REF_NAME environment variable instead of
v$VERSION — i.e. emit tag_name based on $GITHUB_REF_NAME so the publish uses the
exact tag that triggered the run.