Allow bundler to generate sourcemaps files without uploading

[jlowcs]

I'm using the webpack plugin and I wanted to delay the upload of the sourcemaps to after the tagging of our release in our CI. Unfortunately, as I need to generate the files with the debug IDs as part of the build process to generate our integrity hashes, I currently have no choice but to also upload those files during that build process. If I were to run sentry-cli to inject the debug IDs after the fact, different IDs would be generated.

One way to allow for this specific need would be to be able to provide a destination folder for those files, and also disable the upload, e.g.:

    sentryWebpackPlugin({
        sourcemaps: {
            destinationFolder: './sentry-files', // to be uploaded later using sentry-cli
            upload: false, // to disable the upload within the plugin
        },
    })

[Lms24]

Hi @jlowcs thanks for writing in! I'd love to learn more about your use case as to why the delaying of uploading really is necessary.

At this time, there's no "clean" way to specifically disable the upload of source maps but still inject debugIds. We also would like to avoid adding an upload option as suggested because whenever we add such API it will surely be missunderstood and people might use it for the wrong reasons. Generally we want to provide a clear and minimal path how uploading source maps (probably the biggest pain point for Sentry users) can be done.

For the moment, you can work around the issue fairly easily: Specify a non-existing URL in the url option of the plugin. This will make the plugin apply build-time transformations, like injecting the debugIds, but it'll fail during upload. However, "fail" in this case only means that you get an error message. The process will still exit successfully, so it shouldn't impact your CI job.

[jlowcs]

I'd love to learn more about your use case as to why the delaying of uploading really is necessary.

It's a SoC issue within our CI and a concern around multiple build trying to upload the sourcemaps with the same release name.

Our CI works in a very specific way where we build the app, then tag the version (we want to tag only when we know that it builds). In some cases, the build step might run on multiple CI runs for the same release (although only the most recent CI run will be able to actually tag the release), and that could result in us uploading multiple sourcemaps for the same release name.

For the moment, you can work around the issue fairly easily: Specify a non-existing URL in the url option of the plugin. This will make the plugin apply build-time transformations, like injecting the debugIds, but it'll fail during upload. However, "fail" in this case only means that you get an error message. The process will still exit successfully, so it shouldn't impact your CI job.

It does add the debugIds to the source code, but not to the sourcemaps unfortunately. From what I understand reading the sentry code, the sourcemaps are only modified in a /tmp folder for the sole purpose of being uploaded. The original sourcemaps from my build remain without debugIds.

[Lms24]

That's a good point - I missed the second part about the source maps debugId injection. We talked about this a bit and it's unfortunately not trivial to introduce an flag only to inject into source maps but not upload. We're gonna backlog this as a To Do for later.

In the meantime, we're always happy to review PRs for this. Though a PR would need to implement this behaviour in all four plugins.

[jlowcs]

As an intermediate solution, having a way to pass the destination folder for those generated sourcemaps as an option would be helpful. Then that solution you suggested for the url would work.

[Lms24]

It's a SoC issue within our CI and a concern around multiple build trying to upload the sourcemaps with the same release name.

For what it's worth, you don't need to set a release name for debug id-based source map upload. We can match source maps and error stack frames solely on debugId's and don't need to rely on release names anymore. I'm not entirely sure about your setup or how/where you "tag" releases but this is the first time what we're aware of such a setup.

having a way to pass the destination folder for those generated sourcemaps as an option would be helpful.

The problem is that this requires another option as well because we clean up the directory when uploading succeeds but also if it fails. So either way you need to

1. define a directory
2. disable cleanup of this directory

Again, the problem here is introducing public API for a use case we haven't seen much demand for. Whatever we add here can and will lead to confusion down the line. I'm sorry that this is affecting you but for now we'll backlog this.

[jarosik10]

@Lms24 I'm building a Next.js app in a Docker image. During the build process, there is no access to environment variables (including the Sentry auth token). I'd like to upload the source maps as soon as the Docker container runs – right after the application starts. I'm considering using sentry-cli, but as I understand, all source maps created during the build will be deleted. Is that correct?

[jlowcs]

I'm building a Next.js app in a Docker image. During the build process, there is no access to environment variables (including the Sentry auth token).

You could pass those as --build-arg.

I'd like to upload the source maps as soon as the Docker container runs – right after the application starts. I'm considering using sentry-cli, but as I understand, all source maps created during the build will be deleted. Is that correct?

That's my understanding, yes.

[chargome]

@jarosik10 I would rather refer to build secrets for accessing secrets during your build

[andreiborza]

Actually, @s1gr1d and I just found a use case for this too.

For the Nuxt and SolidStart SDKs we use the vite plugin to build and upload sourcemaps, but we also need to use the rollup plugin for the final nitro build step.

Now the problem is that the rollup plugin would detect the previously uploaded sourcemaps as well. At the same time, we cannot tell the vite plugin to ignore the nitro output because the nitro output varies from build preset to build preset.

So we'd like to build but not upload sourcemaps with the vite plugin and then have the rollup plugin upload all detected maps.