feat(sourcemaps): remove ci added step

[obostjancic]

No description provided.

[github-actions]

	Fails
🚫	Please consider adding a changelog entry for the next release.

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Instructions and example for changelog

Please add an entry to CHANGELOG.md to the "Unreleased" section. Make sure the entry includes this PR's number.

Example:

## Unreleased

- remove ci added step ([#673](https://github.com/getsentry/sentry-wizard/pull/673))

If none of the above apply, you can opt out of this check by adding #skip-changelog to the PR description.

Generated by 🚫 dangerJS against 81dcbcb

[Lms24]

I see this is still in draft but what's the motivation for removing this?

[obostjancic]

I see this is still in draft but what's the motivation for removing this?

I was taking a look at the numbers here and it seems like a lot of people are dropping out here (I assume that all no value are aborted). Maybe we could change the wording in this step instead of removing it. 🤷‍♂️

[Lms24]

Hmm I think "empty string" means they probably aborted prior to getting there (?) or they took a branch through the wizard where they're not even confronted with this step.

The reason why we added this step here, was to really tell users that this is an essential step to get everything working correctly in CI (if they actually use CI; that they must have confirmed in a prior prompt). If there's no step, the instructions just rush through to the next point (which might even mean the end of the wizard iirc). So our train of thought was to make that step explicit and have users acknowledge that they have to add this token.

fwiw, I took a look at the dashboard: if we're only interested in the sourcemaps wizard here, I think we should filter the transaction on integration: sourcemaps. Still the "empty string" row has a surprisingly large number. The true/false (false in the sense of "I'll do it later") doesn't surprise me too much though

[Lms24]

I think this query should be more accurate, wdyt?

[obostjancic]

I think this query should be more accurate, wdyt?

Ok yes these numbers make a lot more sense. Thanks for the explanation. Closing this