Release v4 as the Sentry CLI, replacing sentry-cli

Offen
  • Stimmt etwas nicht?
#1,965 1 Kommentar 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@BYK arbeitet bereits daran.

Seit 04.11.2026.

Bewertung

Dieses Issue wurde noch nicht bewertet.

Beschreibung

Tracking issue for cutting sentry v4 as the Sentry CLI. Every v3 sentry-cli distribution channel moves to v4 rather than staying frozen, so nobody gets stranded on v3.

Decided scope

Each legacy channel serves v4 after the cutover:

  • npm @sentry/cli publishes the same package as sentry. The @sentry/cli-<platform> optional-dependency packages need a decision too: retire or keep them. Current consumers use the v3 SentryCli JS class, and v4 drops it (migration guide). These consumers are @sentry/bundler-plugins, @sentry/nextjs, action-release, and the wizard. Their caret ranges protect them until they opt in.
  • curl -sL https://sentry.io/get-cli/ | bash serves the v4 installer. It lives in getsentry/sentry src/sentry/web/frontend/cli.py. SENTRY_CLI_VERSION, INSTALL_DIR / INSTALL_PATH, and | sh keep working.
  • sentry.io/get-cli/<platform>/<arch>/ and downloads.sentry-cdn.com/sentry-cli/latest/ serve v4 binaries. v4 asset names (sentry-linux-x64) differ from v3 (sentry-cli-Linux-x86_64), so this needs a name mapping.
  • PyPI sentry-cli (plus sentry-pypi) ships wheels wrapping the v4 binary.
  • Homebrew sentry-cli and Docker Hub getsentry/sentry-cli move to v4. The legacy getsentry/sentry-cli .craft.yml publishes both.
  • Release registry: the CLI already publishes to apps/sentry. v3 sentry-cli update and its update nagger read apps/sentry-cli/latest, so decide how that app reaches v4.
  • sentry-cli command name: installs keep working for scripts that call sentry-cli.
  • Sentry-hosted binaries: v4 assets currently only live on GitHub Releases. The legacy CLI uploads to the sentry-sdk-assets GCS bucket (downloads.sentry-cdn.com) through a craft gcs target.
  • Codemod: @getsentry/cli3to4 is published on the Codemod registry (#1481). #1968 ported it into packages/codemod-cli3to4, and it publishes from main with Codemod's OIDC action. #1977 points the migration guide at npx codemod@latest @getsentry/cli3to4.

Platform gaps vs v3

v4 builds darwin-arm64, darwin-x64, linux-arm64, linux-x64, and windows-x64 (packages/cli/script/build.ts). v3 also shipped linux-armv7, linux-i686, win32-i686, and win32-arm64, and it ran on musl.

  • musl / Alpine: the installer currently refuses musl (packages/cli/install, detect_musl).
    • x64: nodejs.org/dist ships an official linux-x64-musl build as of v26.13.0. A fossilize 0.10.1 SEA built with platform linux-x64-musl runs on alpine:3 once libstdc++ and libatomic are installed. Without them it fails with relocation errors.
    • arm64: musl is only on unofficial-builds.nodejs.org, and fossilize hardcodes https://nodejs.org/dist.
  • win32-arm64: an official Node build exists (win-arm64).
  • linux-armv7 and i686 have no official Node v26 LTS builds.

Tracked work

Issues and PRs that block or belong to the v4 cutover:

  • #1481: publish the v3→v4 codemod
  • #1968: port the codemod into this repo
  • #1977: point the migration guide at the published codemod
  • #1472: debug-files upload has no progress output (v3 had it)
  • #1473: debug-files upload summary shows numeric IDs instead of slugs
  • getsentry/sentry-cocoa#9169: move the Cocoa test-app scripts to the new CLI
  • getsentry/sentry-fastlane-plugin#536: move the Fastlane plugin to the new CLI
  • getsentry/sentry-maven-plugin#292: plan the Maven plugin migration to the new CLI
  • #1962: install script checksums on GitHub Releases and the release registry

Related: #1357 tracks the broader CLI + MCP unification after the toolkit merge.

via @BYK.

--

View Session [Sentry]

Vorherrschende Sprache
TypeScript
Sterne
957
Forks
174
Ø Merge
16 Std. 43 Min.
Gemergte PRs (30 T.)
390

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus getsentry/toolkit

Alle Issues in getsentry/toolkit

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.