Make SENTRY_DSN_PUBLIC environment variable ready
Closed this issue · 10 comments
According to https://docs.sentry.io/error-reporting/quickstart/?platform=browser the way we'd use Sentry to send browser errors is something like this:
npm install --save @sentry/browserand then, in our React code (at the right place):
import * as Sentry from '@sentry/browser';
Sentry.init({ dsn: SENTRY_PUBLIC_DSN });We need this environment variable to be available at the time we build the JavaScript bundles that get baked inside Docker images.
Note! I don't know what exactly is the best/right variable name.
We currently have SENTRY_DSN so for the public key I propose SENTRY_DSN_PUBLIC.
Note! I don't know what exactly is the best/right variable name.
We currently haveSENTRY_DSNso for the public key I proposeSENTRY_DSN_PUBLIC.
I believe documentation states that SENTRY_DSN is used if there is nothing configured, I think should stick to using SENTRY_DSN
@limed @peterbe I just realized that with this approach, i.e. baking the public DSN into the JS bundle that gets built when the mdnwebdocs/kuma Docker image is built (see https://github.com/mozilla/kuma/blob/74115fbe5aa823667d3f581e45b6e78fae15243c/docker/images/kuma/Dockerfile#L14), we'd need separate mdnwebdocs/kuma Docker images for stage and prod. I suppose one way we could do that is via tagging (e.g., mdnwebdocs/kuma:stage-<commit-hash> and mdnwebdocs/kuma:prod-<commit-hash>). At the very least, that entails changes to our Kuma Jenkins code (generating different tags when building) and our Kuma-based K8s deployments. Is there another way where we can avoid that?
It's probably better to just use separate image names like mdnwebdocs/kuma-stage and mdnwebdocs/kuma-prod, and keep the tagging the same. Of course, this still means the same amount of work in terms of changes to the Jenkins/K8s code.
I'm assuming you're referring to the .js bundle that gets created with the same SENTRY_DSN once gets reused twice (one on stage and one on prod).
It sure sounds very complicated that we have to generate two different docker images.
Wanna close this issue or change its title?
I'm assuming you're referring to the .js bundle that gets created with the same SENTRY_DSN once gets reused twice (one on stage and one on prod).
Yes.
It sure sounds very complicated that we have to generate two different docker images.
Yes. We could do it if we really need/want Sentry in the browser, but it would be nice if we could avoid it.
Wanna close this issue or change its title?
Yes. Unless you feel that we really need Sentry in the browser JS, I'd like to close this issue and instead go with your idea of just using GA's trackError for now.
Yes. Unless you feel that we really need Sentry in the browser JS, I'd like to close this issue and instead go with your idea of just using GA's
trackErrorfor now.
I agree. We can leave this issue open as a record of this topic. I'll redirect my attention to the GA usage inside the error boundaries.
@escattone Can we use same sentry project for stage and production but separte the environement with the environment configuration of sentry?
We can configure the environment dynamically by checking the host domain. What do you think?
For the record, another option would be to pick up the DSN from the DOM. We could use Django jinja to do something like <meta name="sentry" content="{{ settings.SENTRY_DSN_PUBLIC }}"> and in the JS code do document.querySelector('meta[name="sentry"]').content (you get the idea). But doing that might be fraught with risks such as performance of depending on the DOM in the middle of JS execution.
I just generally don't think we should bother with Sentry reporting in the JS code. There are so many problems that would need to be worked out first. For example, we don't want to flood unactionable errors amongst our highly actionable Python Sentry errors.
For example, a strategy is to NOT worry about the details and only exclusively record which pages has the most errors in a time-aggregated fashion. I.e. only look at dimensions of counts with some simpler dimensions such as browser version and URL.