feat(preview releases): update release workflow to mirror that of oth…

…er repositories, preview releases will now be triggered with a PR comment that includes [preview_deployment] on a PR of a branch whose name is prefixed with preview/ (#3039)

.github/workflows/preview-release.yml

@@ -1,17 +1,22 @@
-name: Preview release
-
-on:
-  push:
-    branches:
-      - 'preview/**'
+name: Preview Release on Comment
 
 permissions:
   id-token: write
+  contents: read
+  pull-requests: write
+  issues: write
+
+on:
+  issue_comment:
+    types: [created]
 
 jobs:
-  release:
+  release-preview-on-comment:
+    if: github.event.issue.pull_request && startsWith(github.event.comment.body, '[preview_deployment]')
     runs-on: ubuntu-latest
 
+    timeout-minutes: 15
+
     steps:
       # Get GitHub token via the CT Changesets App
       - name: Generate GitHub token (via CT Changesets App)
@@ -21,23 +26,29 @@ jobs:
           app_id: ${{ secrets.CT_CHANGESETS_APP_ID }}
           private_key: ${{ secrets.CT_CHANGESETS_APP_PEM }}
 
+      - name: Get branch of PR
+        uses: xt0rted/pull-request-comment-branch@v1
+        id: comment-branch
+
+      - name: Validate branch name
+        run: |
+          if [[ ! "$BRANCH_NAME" =~ ^preview/[a-zA-Z0-9_-]+$ ]]; then
+            echo "Ignoring PR because of the branch name. Exiting workflow."
+            exit 1
+          fi
+        env:
+          BRANCH_NAME: ${{ steps.comment-branch.outputs.head_ref }}
+
       - name: Checkout code
         uses: actions/checkout@v4
         with:
           # Pass a personal access token (using our `ct-release-bot` account) to be able to trigger
           # other workflows
           # https://help.github.com/en/actions/reference/events-that-trigger-workflows#triggering-new-workflows-using-a-personal-access-token
           # https://github.community/t/action-does-not-trigger-another-on-push-tag-action/17148/8
+          ref: ${{ steps.comment-branch.outputs.head_ref }}
           token: ${{ steps.generate_github_token.outputs.token }}
 
-      - name: Validate branch name
-        run: |
-          BRANCH_NAME=$(echo "${GITHUB_REF#refs/heads/}" | tr '/' '-')
-          if [[ ! "$BRANCH_NAME" =~ ^preview/[a-zA-Z0-9_-]+$ ]]; then
-            echo "Ignoring PR because of the branch name. Exiting workflow."
-            exit 1
-          fi
-
       - name: Setup Node (uses version in .nvmrc)
         uses: actions/setup-node@v4
         with:
@@ -82,13 +93,12 @@ jobs:
         env:
           GITHUB_TOKEN: ${{ steps.generate_github_token.outputs.token }}
 
-      # Publish preview releases only if the branch starts with "preview/" and the commit message contains "[publish_preview]"
+      # Publish preview releases only if the branch starts with "preview/" and the pr comment contains "[preview_deployment]"
       - name: Publishing preview releases to npm registry
-        if: startsWith(github.ref, 'refs/heads/preview/') && contains(github.event.head_commit.message, '[publish_preview]')
         run: |
           BRANCH_NAME=$(echo "${GITHUB_REF#refs/heads/}" | tr '/' '-')
           git checkout ${{ github.head_ref }}
           yarn changeset version --snapshot ${BRANCH_NAME}
           yarn changeset publish --tag ${BRANCH_NAME}
         env:
-          GITHUB_TOKEN: ${{ steps.generate_github_token.outputs.token }}
+          GITHUB_TOKEN: ${{ steps.generate_github_token.outputs.token }}

CONTRIBUTING.md

@@ -151,11 +151,14 @@ On `main` branch, we automatically publish **canary** releases from CI to the `c
 
 Canary releases are useful to test early changes that should not be released yet to `next` or `latest`. They are automatically triggered and released after a Pull Request merged into `main`.
 
-### Branch-specific canary releases
+### Branch-specific preview release
 
-To release a canary version for a specific branch other than the `main` branch, follow these steps:
+To release a preview release for a specific branch other than the `main` branch, follow these steps:
 
-1. Create a PR with a branch name that starts with the prefix `preview/`  example: `preview/canary-branch`
-2. To avoid creating versions every time we push, to trigger a canary version with your change, the commit message has to contain the trigger string `[publish_preview]` example: `git commit -m"chore(xxx): [publish_preview] test with a commit trigger"` .
+1. Create a PR in github with a branch name that starts with the prefix `preview/`  example: `preview/my-branch`
+2. Make sure that the branch includes a changeset for the packages you want to publish.
+3. Add a comment to the github PR that includes the string `[preview_deployment]`.
+4. The preview release action will add a comment to the PR on success.
+5. The release will be available on npm under an npm tag that is the branch name without `preview/`. If you are releasing `@commercetools-uikit/utils` from the `preview/my-branch`, the preview can be installed as `@commercetools-uikit/utils@my-branch`.
 
 Note that canary releases **will not create git tags and version bump commits**.