chore: pass frontend Sentry DSN#2005
Conversation
There was a problem hiding this comment.
Want to make sure you’ve see #1998 in case it intersects!
| # SENTRY_TRACE_RATE= | ||
|
|
||
| # Optional: configure frontend error reporting | ||
| # Set to your Sentry DSN before `docker compose build` to embed it in the frontend bundle. |
There was a problem hiding this comment.
We can put the second line in docs instead of here!
I haven’t looked deeply at how things are wired but wanted to flag that we’re working to switch to using a pre-built bundle in this release. So no problem if the var needs to be built into the image but it won’t be accessible for bundling.
There was a problem hiding this comment.
#1998 is currently planned for this release because it addresses the significant increase in build memory needed after the Web Forms merger.
I think what would make the most sense for now is to include the DSN in /client-config.json to match the OIDC config.
|
@alxndrsn Could you please review when you have time? PR to pass the DSN to the central-frontend |
|
@alxndrsn this is ready for another look! Thanks! |
Follow-up from this work: getodk/web-forms#803 (PR#1610)
What has been done to verify that this works as intended?
Unit tests are passing. Docker is built with the correct client-config.json
Why is this the best possible solution? Were any other approaches considered?
It follows the same pattern as other variables are passed.
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
Does this change require updates to documentation? If so, please file an issue here and include the link below.
Documented in the README file.
Before submitting this PR, please make sure you have:
nextbranch OR only changed documentation/infrastructure (masteris stable and used in production)