Skip to content

Conversation

@betegon
Copy link
Member

@betegon betegon commented Jan 7, 2026

This PR migrates our release management from Changesets to Craft, Sentry's release tool.

Why Craft?

  • No changeset files: No need to create/commit .changeset/*.md files for each PR
  • Auto-versioning: Version bumps determined automatically from conventional commits
  • Better changelogs: Auto-generated with scope grouping and category organization
  • PR previews: Changelog preview comments on every PR
  • Simpler workflow: All release info lives in commit messages, not extra files

Changes

Removed

  • @changesets/cli and @svitejs/changesets-changelog-github-compact dependencies
  • changeset:* scripts from root package.json
  • prepare-publish.yml workflow

Added

  • .craft.yml - Craft configuration with auto versioning and npm/github targets
  • scripts/bump-version.sh - Version bump script called by Craft
  • .github/release.yml - Changelog categories for conventional commits
  • .github/workflows/release.yml - Craft release workflow
  • .github/workflows/changelog-preview.yml - PR changelog previews
    Updated
  • .github/workflows/build.yml - Trigger on release/** branches
  • .github/workflows/publish.yml - Trigger on changelog changes instead of changeset commit messages
  • Contributor docs updated to explain conventional commits

New Release Flow

  1. Contributors use conventional commits (feat:, fix:, docs:, etc.)
  2. PRs show automatic changelog preview comments
  3. Maintainer triggers "Release" workflow → Craft creates release branch
  4. After merge, publish workflow handles NPM, Docker, and Electron releases

Tested locally:
Screenshot 2026-01-07 at 14 39 55

- Remove @changesets/cli and @svitejs/changesets-changelog-github-compact
- Remove changeset:add, changeset:consume, changeset:publish scripts
- Delete prepare-publish.yml workflow
- Add .craft.yml with auto versioning and changelog generation
- Add scripts/bump-version.sh to update package versions
- Add .github/release.yml for conventional commit changelog categories

Craft will automatically determine version bumps from conventional
commits (feat: → minor, fix: → patch, feat!: → major).
- Update build.yml to trigger on release/** branches
- Add release.yml using Craft's reusable release workflow
- Update publish.yml to trigger on changelog changes
- Add changelog-preview.yml for PR changelog comments
- Update changesets.mdx to explain conventional commits
- Update releases.mdx to document new Craft release process
@vercel
Copy link

vercel bot commented Jan 7, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Review Updated (UTC)
spotlightjs Ready Ready Preview, Comment Jan 9, 2026 7:38pm

@github-actions
Copy link
Contributor

github-actions bot commented Jan 7, 2026

Semver Impact of This PR

🟡 Minor (new features)

📋 Changelog Preview

This is how your changes will appear in the changelog.
Entries from this PR are highlighted with a left border (blockquote style).


New Features ✨

  • Migrate to Craft by betegon in #1232
  • Added a dynamic header for dragbar by MathurAditya724 in #1223
  • Better error message display by MathurAditya724 in #1222

Bug Fixes 🐛

Ui

  • Add validation guards to WebVitalsDetail to prevent crashes by BYK in #1243
  • Handle null/undefined span.description safely by BYK in #1239

Other

  • (sentry) Upload and use source maps for all build targets by BYK in #1241
  • Updated react-router-dom version to latest by MathurAditya724 in #1245
  • Add error handling for base64 decode operations by BYK in #1237
  • Silence non-fixable Sentry errors by BYK in #1242
  • Add null safety to WebVitals comparators by BYK in #1238
  • Add null check for itemHeader in processEnvelope by BYK in #1233
  • Shiki theme in light mode by MathurAditya724 in #1230

Documentation 📚

Website

  • Add feedback note for Spotlight SDK in documentation by MathurAditya724 in #1228
  • Add NextJS guide by betegon in #1129

Other

  • Add section for the spotlight sdk by MathurAditya724 in #1227

Build / dependencies / internal 🔧

  • (deps) Bump @modelcontextprotocol/sdk from 1.24.3 to 1.25.2 by dependabot in #1234
  • Add workflow to notify issues on release by betegon in #1236
  • Using the param instead of calling a function by MathurAditya724 in #1224

Other

  • Node 24.x support by BYK in #1235
  • Vite windows deny bypass by BYK in #1229
  • Qs security vulnerability fix by BYK in #1226
  • Dependency security updates by BYK in #1225
  • Event origin badges ui by BYK in #1221

🤖 This preview updates automatically when you update the PR.

Comment on lines +13 to +15
name: Preview Changelog
uses: getsentry/craft/.github/workflows/changelog-preview.yml@v2
secrets: inherit

Check warning

Code scanning / CodeQL

Workflow does not contain permissions Medium

Actions job or workflow does not limit the permissions of the GITHUB_TOKEN. Consider setting an explicit permissions block, using the following as a minimal starting point: {}

Copilot Autofix

AI 3 days ago

To fix the problem, add an explicit permissions block that restricts the default GITHUB_TOKEN access for this workflow. Because this workflow is only orchestrating a reusable workflow and does not itself perform any direct repository mutations, a safe and conservative default is contents: read. This adheres to the principle of least privilege while still allowing typical read operations (like fetching code) if needed by the reusable workflow.

The best way to fix this without changing existing functionality is:

  • Add a permissions block at the root level of .github/workflows/changelog-preview.yml, alongside name and on, so that it applies to all jobs in the workflow (including the changelog-preview job).
  • Set contents: read as the minimal permission. If the reusable workflow needs additional scopes (for example, pull-requests: write), those should be added there, but we will not assume extra needs beyond contents: read since we cannot see the implementation of the reusable workflow and we must avoid altering behavior more than necessary.

Concretely:

  • In .github/workflows/changelog-preview.yml, after the name: Changelog Preview line, insert:
permissions:
  contents: read

No imports or additional methods are required, as this is a YAML configuration change only.

Suggested changeset 1
.github/workflows/changelog-preview.yml

Autofix patch

Autofix patch
Run the following command in your local git repository to apply this patch
cat << 'EOF' | git apply
diff --git a/.github/workflows/changelog-preview.yml b/.github/workflows/changelog-preview.yml
--- a/.github/workflows/changelog-preview.yml
+++ b/.github/workflows/changelog-preview.yml
@@ -3,6 +3,8 @@
 # https://getsentry.github.io/craft/
 
 name: Changelog Preview
+permissions:
+  contents: read
 on:
   pull_request:
     types: [opened, synchronize, reopened, edited, labeled, unlabeled]
EOF
@@ -3,6 +3,8 @@
# https://getsentry.github.io/craft/

name: Changelog Preview
permissions:
contents: read
on:
pull_request:
types: [opened, synchronize, reopened, edited, labeled, unlabeled]
Copilot is powered by AI and may make mistakes. Always verify output.
Comment on lines 22 to 27
name: Prepare Release
uses: getsentry/craft/.github/workflows/release.yml@v2
with:
version: ${{ inputs.version || 'auto' }}
force: ${{ inputs.force }}
secrets: inherit

Check warning

Code scanning / CodeQL

Workflow does not contain permissions Medium

Actions job or workflow does not limit the permissions of the GITHUB_TOKEN. Consider setting an explicit permissions block, using the following as a minimal starting point: {}

Copilot Autofix

AI about 13 hours ago

In general, the fix is to define an explicit permissions: block that limits the GITHUB_TOKEN to the least privileges required. This can be set at the workflow root (applies to all jobs unless overridden) or for the specific job. Since this workflow only defines one job, adding a root-level permissions: block is simple and avoids changing behavior of the reusable workflow beyond constraining the token permissions.

The best minimal, non-breaking change is to add a workflow-level permissions: block immediately after the name: Release line. If we are unsure exactly which fine-grained permissions the reusable workflow needs, a conservative and still significantly safer default is contents: read, which is GitHub’s recommended minimal baseline. If later we discover that the reusable workflow requires additional scopes (e.g., contents: write, pull-requests: write), those can be added explicitly. For now, we will follow the CodeQL suggestion to define an explicit minimal starting point and use contents: read.

Concretely, edit .github/workflows/release.yml and insert:

permissions:
  contents: read

between the existing name: Release line and the on: block. No imports or additional definitions are needed since this is pure YAML configuration.

Suggested changeset 1
.github/workflows/release.yml

Autofix patch

Autofix patch
Run the following command in your local git repository to apply this patch
cat << 'EOF' | git apply
diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
--- a/.github/workflows/release.yml
+++ b/.github/workflows/release.yml
@@ -2,6 +2,8 @@
 # https://getsentry.github.io/craft/
 
 name: Release
+permissions:
+  contents: read
 on:
   workflow_dispatch:
     inputs:
EOF
@@ -2,6 +2,8 @@
# https://getsentry.github.io/craft/

name: Release
permissions:
contents: read
on:
workflow_dispatch:
inputs:
Copilot is powered by AI and may make mistakes. Always verify output.
@betegon betegon marked this pull request as draft January 7, 2026 13:26
- Update .craft.yml with proper npm and github targets
- Simplify publish.yml to only handle Docker and Electron
- NPM publishing and GitHub releases now handled by getsentry/publish
- Trigger post-release workflow on release:published event

The release flow is now:
1. release.yml -> craft prepare -> creates publish issue
2. getsentry/publish -> craft publish -> npm + GitHub release
3. publish.yml -> Docker tagging + Electron signing
Copy link
Member

@BYK BYK left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Follow up:

  1. Also remove that annoying PR template please
  2. Me to do NPM org/token shenenigans

Explains how the Craft + getsentry/publish release flow works,
including the Post-Release workflow for Docker and Electron.
- Introduced a new GitHub Actions workflow for building the Electron app on macOS.
- Added steps for setting up dependencies, downloading the Electron build, and validating the build files.
- Implemented storage of Electron binaries as artifacts for future use.
- Updated the .craft.yml to include tagging for Electron binaries in the release process.
- Removed the obsolete post-release workflow file.
@betegon betegon marked this pull request as ready for review January 9, 2026 19:37
@betegon betegon requested a review from BYK January 9, 2026 19:45
Copy link
Member

@BYK BYK left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines +22 to +26
uses: getsentry/craft/.github/workflows/release.yml@v2
with:
version: ${{ inputs.version }}
force: ${{ inputs.force }}
secrets: inherit
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need the release to be done by the release bot and the way to use that is like here: https://github.com/getsentry/sentry-wizard/blob/3c21d283fbfc5ce72cac137022102e911a86a290/.github/workflows/release.yml

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need this file?

Comment on lines +34 to +36
- name: docker
source: ghcr.io/getsentry/spotlight
target: ghcr.io/getsentry/spotlight
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what this is supposed to do?

@BYK
Copy link
Member

BYK commented Jan 10, 2026

FYI I added the release/** branches to protection rules and allowed the signing secrets to be used from those branches (through environment: production)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants