Config file name other than `.sentryclirc` not recognized by the plugin

[danielbyun]

Environment

What version are you running? Etc.

    "@sentry/browser": "^7.24.2",
    "@sentry/cli": "^2.10.0",
    "@sentry/react": "^7.24.2",
    "@sentry/tracing": "^7.24.2",
    "@sentry/webpack-plugin": "^1.20.0",

Steps to Reproduce

1. In the webpack.config.js, instantiate new SentryCliPlugin with configFile attribute set to any file not named .sentryclirc
2. example

  new SentryCliPlugin({
    ...
    configFile: './sentryclirc1',
  }),
  new SentryCliPlugin({
    ...
    configFile: './sentryclirc2',
  }),

Expected Result

• during the build source-maps and release are built to the default server and the dsn thats defined int he configuration file

What you thought would happen.

• When build is triggered, sentry-cli should pick up the dsn, token, default.url, etc from the configuration file

Actual Result

• sentry-cli does not detect the configuration file, and searches for .sentryclirc file only. When that exists in the directory, it picks up the values. But when removed, the default server url points to sentry.io, not our internally hosted sentry url.

[lforst]

Just a quick q before I go off and try reproduce this. In the reproduction steps you have set configFile: './sentryclirc2'. Are you sure that this shouldn't be configFile: './.sentryclirc2' instead?

[danielbyun]

Hello,

I have tried both scenarios in the file path and didn't work for me.

[lforst]

Hi, I don't know what the issue is currently and I don't have the cycles to look into this. Just wanted to let you know that we will be sunsetting the .sentryclirc feature for the Webpack plugin soon anyways so you're probably better off just manually passing in any options instead (e.g via env vars and process.env). To me, this seems cleaner anyways.

[danielbyun]

Hello,

What will be the future resolution for tokens if you guys are removing the .sentryclirc feature? We are unable to manually pass the options.

[lforst]

@danielbyun May I ask why you are unable to pass the options?

How about the following?:

new SentryCliPlugin({
  ...
  url: process.env.MY_URL1,
  authToken: process.env.MY_AUTH_TOKEN1
})

new SentryCliPlugin({
  /// ...
  url: process.env.MY_URL2,
  authToken: process.env.MY_AUTH_TOKEN2
})

Afaik the Webpack plugin doesn't use a dsn value to do anything.

[danielbyun]

yeap, so we will initialize both Sentry Plugins with two different authTokens and whatever the dsn value matches with the authToken that instance will log the errors i believe. does that make sense to attempt?

so same release will go on both instances but only one of them will log for that specific release

[lforst]

I don't really understand what you're trying to achieve but if you're attempting what I think you're attempting I would definitely not use the auth token for that.

[danielbyun]

I think your suggestion of

new SentryCliPlugin({
  ...
  url: process.env.MY_URL1,
  authToken: process.env.MY_AUTH_TOKEN1
})

new SentryCliPlugin({
  /// ...
  url: process.env.MY_URL2,
  authToken: process.env.MY_AUTH_TOKEN2
})

should work. we have two self hosted instances of sentry (two dashboards), two releases will go out on each build but each environment will log to the dsn url, once confirmed and verified with the corresponding authToken

[lforst]

Cool that this seems to work for you.

What has me worried is

once confirmed and verified with the corresponding authToken

what are you trying to achieve here? There is no need to verify with an auth token when sending events, nor is it possible with the Sentry webpack plugin out of the box.

Under no circumstances should you inject the auth token into user code at build time. That would be a massive security risk.

[danielbyun]

I apologize, I think I made it sound like we're doing more manual work than the way Sentry is configured.
We're pretty much following the docs to a tee, just initializing the SentryCliPlugin twice for two separate dashboards

new SentryCliPlugin({
  ...
  url: 'hardeded DSN for the first dashboard',
  authToken: process.env.MY_AUTH_TOKEN1 // authToken for the first dashboard's DSN url above
})

new SentryCliPlugin({
  /// ...
  url: 'hardeded DSN for the second dashboard',
  authToken: process.env.MY_AUTH_TOKEN2 // authToken for the second dashboard's DSN url above
})

This will create a release for both dashboards, where the AUTH_TOKEN dictates which dashboard the errors will be reported to.

[lforst]

@danielbyun Good to hear that you are following the docs! The auth token does not dictate where errors are sent to - the auth token is just needed to upload source maps to your project. The DSN dictates where the event is sent. Setting the DSN as url option will not work. Set the url option to the domain of your self hosted instance - NOT the DSN. The DSN should only be set in the SDK.

[danielbyun]

Hi @lforst, sorry I kept mixing the variables 😆

Yes. DSN is set in the SDK, url and authToken will be set during the initialization of Sentry itself.

Your suggestion worked perfectly. Will close this issue.

Thanks!