Releases are duplicated

[gndelia]

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

and 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

My 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?

[lforst]

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.

[lforst]

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.

[lforst]

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.

[gndelia]

@lforst

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?

[lforst]

docs refers only to Sentry.init. So should Sentry.init be called conditionally, and withSentryConfig not?

That's what I recommend. Yes.

[gndelia]

Thank you for all your responses. Doing all of this worked. Releases are no longer duplicated 🎉