36 added, 28 removed. Audit A to A.
---
name: release
description: >
- Cut a new release by triggering the Release workflow via GitHub Actions workflow dispatch.
+ Cut a new release: create the release branch (staging bake), then dispatch the
+ production Release run on that branch.
---
- Cut a new release by triggering the Release workflow via GitHub Actions workflow dispatch.
+ Cut a new release. Releases are a **two-step** process:
- The workflow computes the version itself: a dispatch from `main` takes the latest `v<major>.<minor>.<patch>` tag and increments the patch number. There is no bump-type input — minor/major bumps land by changing the version on `main` first, not through this command.
+ 1. **Branch cut → staging bake**: `create-release-branch.yml` computes the version from the bump type, deletes any stale `release/v<X.Y.Z>` branch, cuts a fresh one from `main` HEAD with the version-bump commit, and pushes it. That push triggers a `Release` run on the branch which is a **staging** deploy (push-triggered and main-dispatched `Release` runs are always staging).
+ 2. **Production**: dispatching `release.yml` **on the `release/v<X.Y.Z>` branch** runs the full production release — tag, GitHub Release, DMG sign/notarize/publish, npm packages, Docker Hub images, iOS TestFlight, platform dependency bump, and the merge-back of the release branch to `main`.
+ The scheduled Tue/Fri 9am ET cut performs step 1 automatically; a human performs step 2 after the staging bake is green. A `release/v<X.Y.Z>` branch with no corresponding GitHub Release means a cut was never promoted — re-running step 1 refreshes it from current `main`.
+
+ The user may pass `$ARGUMENTS` as the bump type for step 1: `patch`, `minor`, `major`, or `hotfix` (patch cut from the latest release tag's commit instead of `main`, pushed `[skip ci]` for manual cherry-picks). Default to `patch`.
+
## Steps
- ### 1. Pull latest main
+ ### 1. Pull latest main and show the payload
```bash
git checkout main && git pull
+ git describe --tags --abbrev=0
+ git log --oneline "$(git describe --tags --abbrev=0)"..origin/main | head -20
```
- The dispatch builds whatever is on `origin/main` — pulling first is so the release you announce matches what you can see locally.
+ Confirm with the user before proceeding unless they already asked for the release explicitly.
- ### 2. Confirm the payload
+ ### 2. Cut the release branch (staging bake)
- Show the latest tag and the commits since it, so it's clear what the release will carry:
+ ```bash
+ gh workflow run create-release-branch.yml \
+ --repo vellum-ai/vellum-assistant \
+ --ref main \
+ --field bump=<patch|minor|major|hotfix>
+ ```
+ Then wait for the branch cut and find the staging `Release` run its push triggered:
+
```bash
- git describe --tags --abbrev=0
- git log --oneline "$(git describe --tags --abbrev=0)"..origin/main | head -20
+ gh run list --workflow="Create Release Branch" --limit 1
+ gh run list --workflow=Release --branch "release/v<X.Y.Z>" --limit 1
```
- Confirm with the user before dispatching unless they already asked for the release explicitly.
+ The version appears in the branch name; the staging run takes ~15-20 minutes. **Wait for it to succeed** — it is the CI bake for the exact release payload. If it fails, fix `main` and re-run this step (it recuts the branch from `main` HEAD).
- ### 3. Trigger the Release workflow
+ ### 3. Dispatch the production release
```bash
gh workflow run release.yml \
--repo vellum-ai/vellum-assistant \
- --ref main
+ --ref "release/v<X.Y.Z>"
```
- The only dispatch input is the optional `slack_user_id` (`--field slack_user_id=U…`), used to attribute the release notification; omit it when unknown.
+ The only dispatch input is the optional `slack_user_id` (`--field slack_user_id=U…`) for the release notification; omit it when unknown.
- The unified Release workflow automatically handles:
- - Computing the next patch version from the latest tag
- - Version bumping across all packages
- - Creating a release branch, PR, and merging it
- - Tagging the release
- - Publishing npm packages
- - Building, signing, notarizing, and publishing the macOS DMG
- - Creating GitHub Releases on `vellum-ai/vellum-assistant`
- - Updating the `vellum-assistant-platform` dependency
+ ### 4. Verify
- ### 4. Verify the workflow started and read the version
+ The production run takes ~20 minutes. When it completes:
```bash
- gh run list --repo vellum-ai/vellum-assistant --workflow="Release" --limit 1
+ gh release list --limit 1 # v<X.Y.Z> should be Latest
+ git fetch --tags && git tag -l "v<X.Y.Z>"
+ git log --oneline origin/main -1 # merge-back commit "Release v<X.Y.Z>"
```
- The computed version appears in the `extract-version` job log as `BASE_VERSION: <x.y.z>`.
+ If the merge-back to main failed, the run's Slack notification includes the manual-merge command.
### 5. Report
Output:
- - The version number (from the `extract-version` job)
- - A link to the running workflow
- - Remind the user that the full release pipeline takes ~15-20 minutes and will auto-publish everything when done
+ - The version number and a link to the production run
+ - Confirmation that the GitHub Release, tag, and merge-back all landed