Revised release and publish workflows #73

mkistler · 2026-01-24T16:42:23Z

This is a second attempt at workflows to create a GitHub release and then publish to nom.

The first attempt failed because it was creating the release directly on main, which ran afoul of the branch protection rules in the repo.

These new workflows create the a "release PR" the bumps the version number in package.json. This PR then needs to be reviewed and merged. When it is merged the second workflow, publish-release, will trigger automatically, create the GitHub release and then publish to npm.

Copilot

Pull request overview

This PR revises the release and publish workflows to comply with branch protection rules by introducing a two-stage release process. Instead of creating releases directly on the main branch, the workflows now create a release PR that requires review before triggering the automated GitHub release and npm publish steps.

Changes:

Removed the old publish.yml workflow that triggered on GitHub release events
Added publish-release.yml workflow that triggers when package.json changes on main, automatically creating a GitHub release and publishing to npm when a version bump commit is detected
Modified create-release.yml to create a release branch with version bump and open a PR instead of directly committing to main

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 8 comments.

File	Description
`.github/workflows/publish.yml`	Removed old workflow that published to npm when a GitHub release was created
`.github/workflows/publish-release.yml`	New workflow that detects version bump commits on main and automatically creates GitHub releases and publishes to npm
`.github/workflows/create-release.yml`	Modified to create a release branch and PR instead of committing directly to main, now includes proper permissions for PR creation

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-01-24T16:45:20Z

.github/workflows/publish-release.yml

+      - name: Publish to npm
+        if: steps.check_commit.outputs.is_version_bump == 'true'
+        env:
+          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
+        run: npm publish


The workflow doesn't run tests or linting before publishing to npm. This is a significant risk as it could publish a broken package. The CI workflow runs on pull requests, but if someone bypasses the PR process or if tests weren't run for any reason, a broken version could be published. Consider adding test and lint steps before the publish step to ensure quality.

@copilot open a new pull request to apply changes based on this feedback

Copilot · 2026-01-24T16:45:21Z

.github/workflows/create-release.yml

+      - name: Create Pull Request
+        id: create_pr
+        uses: peter-evans/create-pull-request@v6
        with:
-          tag_name: ${{ env.new_version }}
-          body: 'Automated release ${{ env.new_version }}.'
+          token: ${{ secrets.GITHUB_TOKEN }}
+          branch: release/${{ env.new_version }}
+          title: 'chore: Release ${{ env.new_version }}'
+          body: |
+            Automated version bump to ${{ env.new_version }}
+
+            This PR was automatically created by the release workflow.
+            Once merged, a GitHub release will be created automatically.
+          base: main


The create-pull-request action is being used on a branch that was already created and pushed manually. This is not the intended usage pattern for this action. The action expects to create the branch itself or work with an existing branch that it manages. Using it after manually pushing may result in unexpected behavior or the action attempting to force-push changes, which could fail. Either let the action handle the entire branch creation and commit process, or use the GitHub CLI or API to create the PR instead.

@copilot open a new pull request to apply changes based on this feedback

Copilot · 2026-01-24T16:45:21Z

.github/workflows/publish-release.yml

+      - name: Create GitHub Release
+        if: steps.check_commit.outputs.is_version_bump == 'true'
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        uses: softprops/action-gh-release@v1
+        with:
+          tag_name: ${{ steps.get_version.outputs.version }}
+          name: Release ${{ steps.get_version.outputs.version }}
+          body: 'Automated release ${{ steps.get_version.outputs.version }}'
+          draft: false
+          prerelease: false


The workflow creates a GitHub release but doesn't verify that the tag doesn't already exist. If the workflow is triggered multiple times (e.g., due to a retry or manual trigger), or if a tag with the same version already exists, the release creation will fail. Consider checking if the tag/release already exists before attempting to create it, or handle the error gracefully.

@copilot open a new pull request to apply changes based on this feedback

Copilot · 2026-01-24T16:45:21Z

.github/workflows/publish-release.yml

+      - name: Create GitHub Release
+        if: steps.check_commit.outputs.is_version_bump == 'true'
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        uses: softprops/action-gh-release@v1
+        with:
+          tag_name: ${{ steps.get_version.outputs.version }}
+          name: Release ${{ steps.get_version.outputs.version }}
+          body: 'Automated release ${{ steps.get_version.outputs.version }}'
+          draft: false
+          prerelease: false
+
+      - name: Publish to npm
+        if: steps.check_commit.outputs.is_version_bump == 'true'
+        env:
+          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
+        run: npm publish


If npm publish fails after the GitHub release has been created, the workflow will leave the repository in an inconsistent state with a release that doesn't correspond to a published npm package. Consider either creating the release after a successful npm publish, or implement error handling to delete the release if publishing fails.

@copilot open a new pull request to apply changes based on this feedback

.github/workflows/create-release.yml

Copilot · 2026-01-24T16:45:21Z

.github/workflows/create-release.yml

+      - name: Create release branch
        run: |
+          BRANCH_NAME="release/${{ env.new_version }}"
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
-          git commit -am "chore: Bump version to $NEW_VERSION"
-          git tag $NEW_VERSION
-          git push origin main --tags
-
-      - name: Create GitHub Release
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        uses: softprops/action-gh-release@v1
+          git checkout -b $BRANCH_NAME
+          git commit -am "chore: Bump version to ${{ env.new_version }}"
+          git push origin $BRANCH_NAME
+
+      - name: Create Pull Request
+        id: create_pr
+        uses: peter-evans/create-pull-request@v6


There's a redundancy issue here. Lines 50-57 manually create a branch, commit changes, and push them using Git commands. Then, the create-pull-request action (lines 59-61) is also configured to work with the same branch. The create-pull-request action can handle creating the branch, committing changes, and pushing automatically if you provide the changed files. This creates unnecessary complexity and potential for conflicts. Consider either removing the manual Git operations and letting the create-pull-request action handle everything, or removing the create-pull-request action and creating the PR using GitHub API.

Copilot · 2026-01-24T16:45:22Z

.github/workflows/publish-release.yml

+      - name: Check if version bump commit
+        id: check_commit
+        run: |
+          commit_message=$(git log -1 --pretty=%B)
+          if [[ "$commit_message" =~ ^chore:\ Bump\ version\ to ]]; then
+            echo "is_version_bump=true" >> $GITHUB_OUTPUT
+          else
+            echo "is_version_bump=false" >> $GITHUB_OUTPUT
+          fi


The commit message check relies on an exact pattern match with 'chore: Bump version to'. However, in a PR merge, especially with squash merges, GitHub may modify the commit message by adding PR numbers or other metadata. This could cause the workflow to fail to recognize valid version bump commits. Consider using a more flexible pattern or checking for changes in the version field of package.json directly instead of relying solely on the commit message.

Copilot · 2026-01-24T16:45:22Z

.github/workflows/publish-release.yml

+on:
+  push:
+    branches:
+      - main
+    paths:
+      - 'package.json'


The workflow triggers on any push to main that modifies package.json. This means it will run even when package.json is updated for reasons other than version bumps (e.g., dependency updates, metadata changes). While the commit message check should filter these out, it's inefficient and may cause confusion. Consider adding a more specific trigger condition or documenting this behavior more clearly.

Copilot · 2026-01-27T14:32:58Z

@mkistler I've opened a new pull request, #75, to work on those changes. Once the pull request is ready, I'll request review from you.

Copilot · 2026-01-27T14:33:41Z

@mkistler I've opened a new pull request, #76, to work on those changes. Once the pull request is ready, I'll request review from you.

Copilot · 2026-01-27T14:34:05Z

@mkistler I've opened a new pull request, #77, to work on those changes. Once the pull request is ready, I'll request review from you.

Copilot · 2026-01-27T14:34:19Z

@mkistler I've opened a new pull request, #78, to work on those changes. Once the pull request is ready, I'll request review from you.

Co-authored-by: mkistler <800728+mkistler@users.noreply.github.com>

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Add test and lint steps to publish workflow

mkistler · 2026-01-28T12:39:17Z

I'm going to start over on this.

Revised release and publish workflows

3cd5cca

mkistler requested a review from Copilot January 24, 2026 16:42

mkistler assigned rambleraptor Jan 24, 2026

Copilot started reviewing on behalf of mkistler January 24, 2026 16:42 View session

Copilot AI reviewed Jan 24, 2026

View reviewed changes

Initial plan

afb933c

Copilot AI mentioned this pull request Jan 27, 2026

Add test and lint steps to publish workflow #75

Merged

Copilot AI mentioned this pull request Jan 27, 2026

Replace create-pull-request action with gh CLI in release workflow #76

Closed

Copilot AI mentioned this pull request Jan 27, 2026

Add tag existence check to prevent duplicate release creation #77

Closed

Copilot AI mentioned this pull request Jan 27, 2026

Reverse workflow order: publish to npm before creating GitHub release #78

Closed

Copilot AI and others added 3 commits January 27, 2026 14:34

Add tests and linting to publish workflow before npm publish

92f6c77

Co-authored-by: mkistler <800728+mkistler@users.noreply.github.com>

Apply suggestion from @Copilot

816624d

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Merge pull request #75 from aep-dev/copilot/sub-pr-73

56b2179

Add test and lint steps to publish workflow

mkistler closed this Jan 28, 2026

mkistler deleted the mdk/publish-to-npm branch January 28, 2026 15:25

Revised release and publish workflows #73

Revised release and publish workflows #73

Uh oh!

Conversation

mkistler commented Jan 24, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Jan 24, 2026

Choose a reason for hiding this comment

Uh oh!

mkistler Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 24, 2026

Choose a reason for hiding this comment

Uh oh!

mkistler Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 24, 2026

Choose a reason for hiding this comment

Uh oh!

mkistler Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 24, 2026

Choose a reason for hiding this comment

Uh oh!

mkistler Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI Jan 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI commented Jan 27, 2026

Uh oh!

Copilot AI commented Jan 27, 2026

Uh oh!

Copilot AI commented Jan 27, 2026

Uh oh!

Copilot AI commented Jan 27, 2026

Uh oh!

mkistler commented Jan 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants