feat: add vite-plugin sentry #1991
|
|
@ -74,8 +74,6 @@ steps:
|
|||
from_secret: sentry_auth_token
|
||||
SENTRY_ORG: vikunja
|
||||
|
|
||||
SENTRY_PROJECT: frontend-oss
|
||||
SENTRY_RELEASE:
|
||||
from_secret: sentry_release
|
||||
commands:
|
||||
- corepack enable && pnpm config set store-dir .cache/pnpm
|
||||
- pnpm run build
|
||||
|
|
|
|||
|
|
@ -24,7 +24,6 @@ interface ImportMetaEnv {
|
|||
readonly SENTRY_AUTH_TOKEN?: string
|
||||
readonly SENTRY_ORG?: string
|
||||
readonly SENTRY_PROJECT?: string
|
||||
readonly SENTRY_RELEASE?: string
|
||||
|
||||
readonly VITE_WORKBOX_DEBUG?: boolean
|
||||
readonly VITE_IS_ONLINE: boolean
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ function getSentryConfig(env: ImportMetaEnv): ViteSentryPluginOptions {
|
|||
authToken: env.SENTRY_AUTH_TOKEN,
|
||||
dpschen
commented
If I got this correctly we should probably improve this to have dedicated Sentry environments for areas like:
We also might want to add other properties of deploy. If I got this correctly we should probably improve this to have [dedicated Sentry environments](https://sentry.io/settings/vikunja/projects/frontend-oss/environments/) for areas like:
- dev
- try
- production
- maybe the pull request previews
- ???
We also might want to add [other properties of deploy](https://github.com/ikenfin/vite-plugin-sentry#deploy-settings).
konrad
commented
Can we pass arbitrary strings to sentry to set the environment? Can we pass arbitrary strings to sentry to set the environment?
konrad
commented
I think the environment setting should depend on the bundle type. Things like try should be a name, not an environment. Maybe something like that:
I think the environment setting should depend on the bundle type. Things like try should be a name, not an environment. Maybe something like that:
* production - default, used for try etc
* dev - used for dev builds (`env.mode === 'development'` or similar)
* pr - used for preview envs in PRs
* ci - (not sure if we're even enabling sentry in ui tests?)
dpschen
commented
We track currently in Asking because if we do remove that I guess we find much less errors with the help of people trying out Vikunja :) We track currently in `try` right?
Asking because if we do remove that I guess we find much less errors with the help of people trying out Vikunja :)
konrad
commented
Yes, we currently track in try. I'd keep it enabled but as a Yes, we currently track in try. I'd keep it enabled but as a `production` env (because it's a production build) and add try as a deployment name.
|
||||
org: env.SENTRY_ORG,
|
||||
project: env.SENTRY_PROJECT,
|
||||
release: env.SENTRY_VERSION || VERSION,
|
||||
release: VERSION,
|
||||
deploy: {
|
||||
env: env.mode === 'production'
|
||||
? 'production'
|
||||
|
|
|
|||
Reference in New Issue
Why should this be a secret? Shouldn't this be the same as
window.version?window.versiondoesn't exist? Do you mean getting the version number fromversion.json?Yes, I meant that, sorry for the confusion
If we work locally that doesn't include the current commit, right?
Still not sure what I should do here now.
It will only include the last commit. I'd argue building for prod locally is an edge case where we can set the version manually. No need to overcomplicate things