sentry-setup-releases

Set Up Sentry Releases

Without a release, an issue tells you what broke but nothing about when it started or what changed. This skill wires that up end to end: the version tag on events, the release created in CI with its commits and deploy, and the suspect-commit path that turns an issue into a culprit PR.

The whole setup fails silently — every piece can be individually correct while producing nothing visible — so this skill’s real job is to diagnose which piece is missing before configuring anything.

Wrong skill? If Sentry isn’t installed and capturing events yet, start with sentry-instrument — releases decorate events you already receive. If the complaint is minified or unsymbolicated frames, that’s sentry-fix-stack-traces (readable frames are a prerequisite for suspect commits, so you may come back here after). If the goal is fixing one specific issue rather than setting up the wiring, that’s sentry-debug-issue. Note that sentry-get-started and sentry-instrument set the release tag during setup, using the same references — this skill is the entry point for the CI half and for a release feature that isn’t working.

Step 1 — Establish which half exists before configuring anything

Do not start writing CI config. Most projects arrive here partially set up, and the fix depends entirely on which half is missing. Read the diagnosis table in references/releases/index.md and answer its two questions:

• Are events tagged? Pull a recent event via the MCP (search_issues, then get_sentry_resource) and read its release tag. Note the exact value — you will compare it character for character.
• Does the release object exist under that name? This is a different question, and an event search cannot answer it — release:<value> only tells you events carry the tag, which you already know from the previous bullet. Call get_release_details with that exact version: it returns the commits and deploys attached to the release — deploys with their environment, commits with author and repository — which is what tells you whether the CI half ran. If you don’t have the exact string, find_releases lists releases with a lastCommit / lastDeploy summary on each, enough to see at a glance which ones CI touched. Both are catalog tools and usually aren’t exposed directly — reach them via search_sentry_tools / execute_sentry_tool. Also grep the repo for what is already wired: a Sentry bundler plugin in the build config, getsentry/action-release in a workflow, sentry-cli releases in a deploy script.