Switch from .reporterrors file to flag + envvar

[chadwhitacre]

The .reporterrors file is a somewhat idiosyncratic way to configure the sentry installer. We use environment variables and CLI flags for other configuration, we don't have a proper configuration file for the installer itself (vs. the runtime config files in sentry/). This PR switches to using envvars and CLI flags to configure whether we report to Sentry.

This also expands the scope of the ask to allow for future expansion into runtime data collection. We're starting with just the installer but we don't want to have to go through the consent exercise again in the future if we don't have to, better to ask once up front here.

[emmatyping]

The .reporterrors file is a somewhat idiosyncratic way to configure the sentry installer.

I wanted some way to persist the user's choice since in the non-interactive case, I imagined a user coming along, running the updated installer, making a choice, then completely forgetting the choice was made in the future. The persisted file would avoid users having to remember every time that they need to opt in or out of error collection. I expect if we don't prompt them every month users are more likely to stay opted-in to error collection.

Perhaps a more robust solution is a config file which is similar to a .env file (each option is just the environment variable setting?). e.g. they can put REPORT_TO_SENTRY=1 in a file somewhere?

[hubertdeng123]

I think we should also update the readme for this to include information here

[hubertdeng123]

Perhaps a more robust solution is a config file which is similar to a .env file (each option is just the environment variable setting?). e.g. they can put REPORT_TO_SENTRY=1 in a file somewhere?

What's the harm in using the .env file?

[emmatyping]

What's the harm in using the .env file?

The .env files is more meant for runtime, not install time. Also if a user does the following things could break:

• set option in .env
• override that option when running the installer e.g. via CLI
• docker will read from .env not CLI

Also, ideally we'd be able to persist the error collection choice of users, but updating the .env file would be harder to do.

[hubertdeng123]

Ah yeah, I guess it's better to leave installation configs separate from runtime

[chadwhitacre]

Automerge enabled! Here we gooooo!

[chadwhitacre]

I did some bikeshedding on the naming of the flags/vars by looking at parallels with SENTRY_BEACON, SENTRY_SKIP_UPSTREAM_REPORTING and https://docs.sentry.io/product/sentry-basics/key-terms/. I tried to come up with something that avoided the confusion of "Like, is Sentry forwarding my own events upstream to their server, Relay-style?" No, we're sending issues that arise with your self-hosted instance itself. I also tried to be generic enough to cover future expansion as mentioned. "Issues" is generic and encompasses all sorts of things, from errors to performance to whatever else we come up with. I also didn't want to make the names too long. :)