Currently, when sending Sentry errors, the API uses the SENTRY_ENVIRONMENT environment variable to tell Sentry whether the error is coming from development or production. However, all the other Nebula projects do not even send Sentry errors from development.
To disable Sentry, it should work to initialize it without a DSN in api/server.go. Update the code in api/server.go to initialize Sentry with a DSN from a new environment variable, SENTRY_DSN. Then after merge we will specify SENTRY_DSN only in the environment variables available to the production API.
Make sure the API compiles and works when SENTRY_DSN is not specified in a users environment variables so that every API team member doesn't need to have something like SENTRY_DSN="" in their .env file.
Currently, when sending Sentry errors, the API uses the
SENTRY_ENVIRONMENTenvironment variable to tell Sentry whether the error is coming from development or production. However, all the other Nebula projects do not even send Sentry errors from development.To disable Sentry, it should work to initialize it without a DSN in
api/server.go. Update the code inapi/server.goto initialize Sentry with a DSN from a new environment variable,SENTRY_DSN. Then after merge we will specifySENTRY_DSNonly in the environment variables available to the production API.Make sure the API compiles and works when
SENTRY_DSNis not specified in a users environment variables so that every API team member doesn't need to have something likeSENTRY_DSN=""in their.envfile.