feat: drop dev branch and improve release notes#637
Conversation
📝 WalkthroughWalkthroughPublish workflow behavior moved to master: manual dispatch supports explicit release types, commit-message detection can bump minor vs patch, workflow now creates/pushes git tags and GitHub Releases post-publish, deprecated stable workflow removed, and related npm release scripts deleted. Changes
Sequence Diagram(s)sequenceDiagram
actor Dev as Developer
participant GH as GitHub (Push / Dispatch)
participant Actions as GitHub Actions / publish workflow
participant Git as Git (tags)
participant NPM as npm Registry
participant GHRel as GitHub Releases
participant Slack as Slack
rect rgba(200,230,201,0.5)
Dev->>GH: push / workflow_dispatch (release_type)
end
GH->>Actions: trigger publish workflow
Actions->>Actions: determine release type (dispatch vs commit message)
Actions->>Actions: run versioning & build
Actions->>NPM: publish packages (dist-tag)
Actions->>Git: create & push v<version> tag (if missing & master)
Actions->>GHRel: create release for v<version> (if master & not exists)
Actions->>Slack: broadcast publish notification
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/publish.yaml (1)
266-273:⚠️ Potential issue | 🔴 CriticalUpdate downstream branch targets in
.github/workflows/package-bump.yamlbefore triggering package bumps on prod releases.Verification shows all 9 downstream package-bump target branches are currently missing or inaccessible. The workflow will fail on the first prod release if these branches don't exist. Confirm which branches are active in each downstream repo and update the branch targets accordingly (currently targets a mix of
master,dev, andstaging).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/publish.yaml around lines 266 - 273, The "trigger-package-bumps" workflow invokes .github/workflows/package-bump.yaml for prod releases but that downstream workflow's branch targets are incorrect/missing; open package-bump.yaml and update the nine downstream branch targets to the actual active branches for each downstream repo (replace any incorrect uses of master/dev/staging), then verify each downstream repository has the referenced branch and adjust the branch names or create branches as needed so the job guarded by needs.publish.outputs.publish_type == 'latest' can run successfully.
🤖 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 235-256: The "Create GitHub Release" step (using VERSION/TAG, git
tag/git push and gh release create) runs after npm publish which can leave npm
ahead of git if tagging/pushing fails; fix by making tag creation and git push
idempotent and move it before the irreversible publish (or add a dedicated
pre-publish job): ensure the workflow creates and pushes the TAG (use git tag
"$TAG" and git push origin "$TAG" or git push --follow-tags) before any publish
steps, and keep the gh release create step separate and tolerant (check gh
release view "$TAG" before create) so re-runs won't cause extra versions; update
the "Create GitHub Release" step into a pre-publish "Create and Push Tag" job or
reorder steps to persist git state prior to publishing.
- Around line 15-29: Add a workflow-level concurrency block to
.github/workflows/publish.yaml so release runs queue instead of racing: under
the top-level (same level as on and workflow_dispatch) add a concurrency key
(e.g. concurrency: group: 'publish-release' or use a stable expression like
'publish-${{ github.repository }}' and set cancel-in-progress: false) to
serialize executions that run lerna version / npm publish / tag pushes / GitHub
Releases; ensure the concurrency group is stable across push and
workflow_dispatch invocations (refer to workflow_dispatch and release_type) so
overlapping release runs cannot compute the same next version.
---
Outside diff comments:
In @.github/workflows/publish.yaml:
- Around line 266-273: The "trigger-package-bumps" workflow invokes
.github/workflows/package-bump.yaml for prod releases but that downstream
workflow's branch targets are incorrect/missing; open package-bump.yaml and
update the nine downstream branch targets to the actual active branches for each
downstream repo (replace any incorrect uses of master/dev/staging), then verify
each downstream repository has the referenced branch and adjust the branch names
or create branches as needed so the job guarded by
needs.publish.outputs.publish_type == 'latest' can run successfully.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 694c8725-423e-4827-a159-ad54d41ec640
📒 Files selected for processing (4)
.github/workflows/package-bump.yaml.github/workflows/publish.yaml.github/workflows/stable.yamlpackage.json
💤 Files with no reviewable changes (2)
- .github/workflows/stable.yaml
- package.json
ThomasRalee
force-pushed
the
feat/drop-dev-branch-and-improve-release-notes
branch
from
d13e5e0 to
2858292
Compare
There was a problem hiding this comment.
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 56-61: The workflow allows workflow_dispatch to run on tags
causing detached-HEAD failures and leaves TYPE/DIST_TAG/VERSION_ARGS unset for
unknown release_type; update the job condition to require startsWith(github.ref,
'refs/heads/') for manual dispatch paths (so workflow_dispatch runs must target
a branch), add an explicit branch/ref validation before invoking lerna
version/git push (guard the lerna/version/push steps with a check that
github.ref startsWith 'refs/heads/'), and add a final else branch when parsing
inputs.release_type to explicitly fail with a helpful error or set safe defaults
for TYPE, DIST_TAG and VERSION_ARGS if release_type is unrecognized so
downstream steps cannot proceed silently.
- Around line 199-208: The workflow currently only checks for local tags using
git rev-parse and can skip pushing a missing remote tag, causing gh release
create to auto-create a tag on the wrong commit; update the "Create and push
release tag" step that sets VERSION/TAG so it verifies the tag on the remote
(use git ls-remote --exit-code origin "refs/tags/$TAG" or equivalent) and only
creates/pushes the local tag when the remote tag is absent, and also add the
--verify-tag flag to the gh release create invocation so gh release create will
fail if the tag is not present on the remote.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 9edfb0ef-d6e9-4d8e-804f-527f76f4ac00
📒 Files selected for processing (4)
.github/workflows/package-bump.yaml.github/workflows/publish.yaml.github/workflows/stable.yamlpackage.json
💤 Files with no reviewable changes (2)
- .github/workflows/stable.yaml
- package.json
✅ Files skipped from review due to trivial changes (1)
- .github/workflows/package-bump.yaml
| github.ref == 'refs/heads/master' || | ||
| contains(github.event.head_commit.message, 'canary') || | ||
| contains(github.event.head_commit.message, 'beta') | ||
| contains(github.event.head_commit.message, 'beta') || | ||
| github.event_name == 'workflow_dispatch' | ||
| ) && | ||
| !(github.ref == 'refs/heads/dev' && github.event_name == 'workflow_dispatch') | ||
| !(github.ref == 'refs/heads/master' && github.event_name == 'workflow_dispatch' && inputs.release_type != 'prod') |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/publish.yamlRepository: InjectiveLabs/injective-ts
Length of output: 12507
Validate that manual dispatch releases target a branch, and handle unknown release types.
workflow_dispatch runs can target any git ref (branch or tag), but lines 56–61 admit all manual runs without ref validation. Lines 122–129 (canary and beta handlers) skip branch checking entirely—only prod validates at line 115. This allows a canary or beta dispatch on a tag to reach lerna version and git push at lines 193–197, where it fails against a detached HEAD. Additionally, an unknown release_type leaves TYPE, DIST_TAG, and VERSION_ARGS unset, causing silent failures downstream.
Add startsWith(github.ref, 'refs/heads/') to the job condition (line 59), validate branch refs before lerna version, and add an explicit else clause to catch unrecognized release_type values.
🛠️ Proposed fix
(
github.ref == 'refs/heads/master' ||
contains(github.event.head_commit.message, 'canary') ||
contains(github.event.head_commit.message, 'beta') ||
- github.event_name == 'workflow_dispatch'
+ (github.event_name == 'workflow_dispatch' && startsWith(github.ref, 'refs/heads/'))
) &&
!(github.ref == 'refs/heads/master' && github.event_name == 'workflow_dispatch' && inputs.release_type != 'prod')
...
# Handle workflow_dispatch input
if [[ "${{ github.event_name }}" == "workflow_dispatch" ]]; then
RELEASE_TYPE="${{ inputs.release_type }}"
if [[ "$RELEASE_TYPE" == "prod" ]]; then
if [[ "$BRANCH" != "refs/heads/master" ]]; then
echo "::error::prod releases can only be triggered from the master branch"
exit 1
fi
@@ -127,6 +127,10 @@ run: |
elif [[ "$RELEASE_TYPE" == "beta" ]]; then
TYPE="beta"
DIST_TAG="beta"
VERSION_ARGS="prerelease --preid beta --force-publish --force-git-tag --no-changelog --yes --no-push"
+ else
+ echo "::error::Unsupported release_type: $RELEASE_TYPE"
+ exit 1
fi
echo "type=$TYPE" >> $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 56 - 61, The workflow allows
workflow_dispatch to run on tags causing detached-HEAD failures and leaves
TYPE/DIST_TAG/VERSION_ARGS unset for unknown release_type; update the job
condition to require startsWith(github.ref, 'refs/heads/') for manual dispatch
paths (so workflow_dispatch runs must target a branch), add an explicit
branch/ref validation before invoking lerna version/git push (guard the
lerna/version/push steps with a check that github.ref startsWith 'refs/heads/'),
and add a final else branch when parsing inputs.release_type to explicitly fail
with a helpful error or set safe defaults for TYPE, DIST_TAG and VERSION_ARGS if
release_type is unrecognized so downstream steps cannot proceed silently.
| - name: Create and push release tag | ||
| if: github.ref == 'refs/heads/master' | ||
| run: | | ||
| VERSION=$(node -p "require('./packages/sdk-ts/package.json').version") | ||
| TAG="v${VERSION}" | ||
|
|
||
| if ! git rev-parse --verify "refs/tags/$TAG" >/dev/null 2>&1; then | ||
| git tag "$TAG" | ||
| git push origin "$TAG" | ||
| fi |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cd /tmp/repo && find . -name "publish.yaml" -type f | head -5Repository: InjectiveLabs/injective-ts
Length of output: 129
🏁 Script executed:
# First, let's find the publish workflow file
fd -t f "publish.yaml" | head -1Repository: InjectiveLabs/injective-ts
Length of output: 52
🏁 Script executed:
# Read the workflow file to check the actual content at the mentioned lines
if [ -f ".github/workflows/publish.yaml" ]; then
cat -n .github/workflows/publish.yaml | sed -n '195,215p'
fiRepository: InjectiveLabs/injective-ts
Length of output: 967
🏁 Script executed:
# Also check the lines around 250-263
if [ -f ".github/workflows/publish.yaml" ]; then
cat -n .github/workflows/publish.yaml | sed -n '245,268p'
fiRepository: InjectiveLabs/injective-ts
Length of output: 1023
🌐 Web query:
gh release create --verify-tag flag documentation
💡 Result:
In GitHub CLI (gh), the --verify-tag flag for gh release create means:
- By default, if the tag you pass doesn’t exist,
gh release create <tag>will auto-create the tag from the repository’s default branch (or from--targetif you provide it). - With
--verify-tag,ghwill abort instead of creating the release if the tag doesn’t already exist in the repo. [1]
Official documentation: gh release create manual page. [1]
Example
gh release create v1.2.3 --verify-tagSources: [1] (cli.github.com)
Citations:
🌐 Web query:
git ls-remote check remote tags documentation
💡 Result:
To check remote tags with git ls-remote, the official documentation is the git-ls-remote man page. It explains the key options:
-
List all tags on a remote:
git ls-remote --tags origin
[1]
-
Check whether a specific tag exists on the remote (by fully-qualified refname):
git ls-remote origin refs/tags/<tag-name>
[5]
-
Avoid “double lines” for annotated tags (where you might otherwise see both
refs/tags/v1.0andrefs/tags/v1.0^{}) by adding--refs:git ls-remote --tags --refs origin
[1]
Docs: Git - git-ls-remote Documentation (official) [1]
Sources: [1] [5]
🏁 Script executed:
# Check gh release create help for --verify-tag option
gh release create --help 2>&1 | grep -A 5 "verify-tag" || echo "Flag not found in help"Repository: InjectiveLabs/injective-ts
Length of output: 707
🏁 Script executed:
# Verify git ls-remote syntax for checking remote tags
man git-ls-remote 2>&1 | grep -A 10 "exit-code" || git ls-remote --help 2>&1 | head -50Repository: InjectiveLabs/injective-ts
Length of output: 167
Add --verify-tag flag to gh release create and verify remote tag before pushing.
The current code only checks for local tags (line 205). If a local tag exists but the remote tag doesn't, the push is skipped. Then gh release create without --verify-tag auto-creates the tag from the default branch's current state, tying the release to the wrong commit.
Add --verify-tag to the release creation step (line 259) to abort if the tag doesn't already exist on the remote. Additionally, check that the tag exists on the remote before deciding to push:
Proposed fix
- name: Create and push release tag
if: github.ref == 'refs/heads/master'
run: |
VERSION=$(node -p "require('./packages/sdk-ts/package.json').version")
TAG="v${VERSION}"
- if ! git rev-parse --verify "refs/tags/$TAG" >/dev/null 2>&1; then
- git tag "$TAG"
- git push origin "$TAG"
+ if ! git ls-remote --exit-code origin "refs/tags/$TAG" >/dev/null 2>&1; then
+ if ! git rev-parse --verify "refs/tags/$TAG" >/dev/null 2>&1; then
+ git tag "$TAG"
+ fi
+ git push origin "$TAG"
fi
...
if ! gh release view "$TAG" >/dev/null 2>&1; then
gh release create "$TAG" \
+ --verify-tag \
--title "$TAG" \
--generate-notes \
--latest
fi🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/publish.yaml around lines 199 - 208, The workflow
currently only checks for local tags using git rev-parse and can skip pushing a
missing remote tag, causing gh release create to auto-create a tag on the wrong
commit; update the "Create and push release tag" step that sets VERSION/TAG so
it verifies the tag on the remote (use git ls-remote --exit-code origin
"refs/tags/$TAG" or equivalent) and only creates/pushes the local tag when the
remote tag is absent, and also add the --verify-tag flag to the gh release
create invocation so gh release create will fail if the tag is not present on
the remote.
1 participant
Summary by CodeRabbit