- 
 
- 
  Notifications
 You must be signed in to change notification settings 
- Fork 1.7k
-
I've a Nextjs app with Typescript. On a Github action, after merging to main, the CI builds a static up + uploads into a hosting service + uses the Sentry GitHub action to notify about the release. However, I get duplicated releases in sentry.
This is my config:
sentry.client.config.ts
import * as Sentry from '@sentry/nextjs' Sentry.init({ dsn: process.env.NEXT_PUBLIC_SENTRY_DSN, enabled: !!process.env.NEXT_PUBLIC_SENTRY_DSN, environment: process.env.NEXT_PUBLIC_SENTRY_ENVIRONMENT || 'staging', integrations: [ // This overrides the default implementation of the RewriteFrames // integration from sentry/nextjs. It adds the decodeURI() to fix a mismatch // of sourceMaps in reported issues. // ref: https://github.com/getsentry/sentry/issues/19713#issuecomment-696614341 Sentry.rewriteFramesIntegration({ iteratee(frame) { const { origin } = new URL(frame.filename) frame.filename = decodeURI(frame.filename.replace(origin, 'app://')) return frame }, }), ], release: `my-app@${process.env.NEXT_PUBLIC_RELEASE_VERSION}`, tracesSampleRate: 1, })
this is my next.config.js
'use strict' const { withSentryConfig } = require('@sentry/nextjs') /** @type {import('next').NextConfig} */ const nextConfig = { experimental: { instrumentationHook: true, }, // images are exported on demand, which is incompatible with static export output: 'export', reactStrictMode: true, trailingSlash: true, webpack(config) { config.resolve.fallback = { fs: false, net: false, tls: false } config.externals.push('pino-pretty', 'lokijs', 'encoding') return config }, } /** @type {import('@sentry/nextjs').SentryBuildOptions} */ const sentryOptions = { authToken: process.env.SENTRY_AUTH_TOKEN, hideSourceMaps: true, org: process.env.SENTRY_ORG, project: process.env.SENTRY_PROJECT, // value here would be "my-app" widenClientFileUpload: true, } module.exports = withSentryConfig(nextConfig, sentryOptions)
All env variables are properly set. NEXT_PUBLIC_RELEASE_VERSION is generated from another process with a YYYYMMDD_N string properly.
My understanding, per these setup docs is that I just need to use the Sentry Github Action to notify after generating the build.
So this is my github action code (a simplified version for easy reading)
jobs: build-and-deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: hemilabs/actions/setup-node-env@main - name: Deploy uses: ./.github/actions/deploy with: NEXT_PUBLIC_RELEASE_VERSION: ${{ github.event.release.name }} NEXT_PUBLIC_SENTRY_DSN: ${{ vars.NEXT_PUBLIC_SENTRY_DSN_PROD }} NEXT_PUBLIC_SENTRY_ENVIRONMENT: production SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN_PROD }} SENTRY_ORG: ${{ vars.SENTRY_ORG }} SENTRY_PROJECT: ${{ vars.SENTRY_PROJECT }} - name: Create Sentry release uses: getsentry/action-release@v1 env: SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_INTEGRATION_TOKEN }} SENTRY_ORG: ${{ vars.SENTRY_ORG }} SENTRY_PROJECT: ${{ vars.SENTRY_PROJECT }} with: environment: production version: ${{ format('{0}@{1}', vars.SENTRY_PROJECT, github.event.release.name) }} # this matches "release" property in sentry.client.config.ts
This generates 2 releases for me, though there are slightly different: One is created during the build, has no proper name, but it has all the source-maps, and environment is not set
imageand the other one seems to be created from the Github Action, has the appropriate name, doesn't have the source maps, has the environment set, and is the one that receives the events
imageMy understanding from the docs is that the integration was needed to notify Sentry about the release, but why is the next build step also creating a release? Is it because I am setting the release property? Should I remove it?
Beta Was this translation helpful? Give feedback.
All reactions
The Next.js creates a release by itself. You can likely just pass a SENTRY_RELEASE env var to your build job and remove the getsentry/action-release action.
Replies: 1 comment 8 replies
-
The Next.js creates a release by itself. You can likely just pass a SENTRY_RELEASE env var to your build job and remove the getsentry/action-release action.
Beta Was this translation helpful? Give feedback.
All reactions
-
Make sure you pass the release.name and release.deploy.env options to withSentryConfig and remove only the release value from the Sentry.init() options. The build will inject the release in the client bundles.
Beta Was this translation helpful? Give feedback.
All reactions
-
In general I would also really recommend not conditionally calling withSentryConfig but instead always call it. Sentry will gracefully degrade if these variables aren't there.
Beta Was this translation helpful? Give feedback.
All reactions
-
Make sure you pass the release.name and release.deploy.env options to withSentryConfig and remove only the release value from the Sentry.init() options. The build will inject the release in the client bundles.
Thanks for this! I did not notice that there was a release option defined in withSentryConfig. I was using Sentry.init because I saw that in the configuration options. I missed the other one
In general I would also really recommend not conditionally calling withSentryConfig but instead always call it. Sentry will gracefully degrade if these variables aren't there.
We only have 2 envs (well, 3 if we count a local env): Staging and Prod. Sentry will be disabled for staging, and enabled for prod. It is unlikely it will change. We got the idea of calling it conditionally from the enabled docs as well (See here). Of course, that docs refers only to Sentry.init. So should Sentry.init be called conditionally, and withSentryConfig not?
Beta Was this translation helpful? Give feedback.
All reactions
-
docs refers only to Sentry.init. So should Sentry.init be called conditionally, and withSentryConfig not?
That's what I recommend. Yes.
Beta Was this translation helpful? Give feedback.
All reactions
-
Thank you for all your responses. Doing all of this worked. Releases are no longer duplicated 🎉
Beta Was this translation helpful? Give feedback.
All reactions
- 
 ❤️ 1