Closed kseniyashaydurova closed 1 year ago
@kseniyashaydurova I am unable to login into sentry
@kseniyashaydurova when I'm opening release info https://sentry.saritasa.rocks/organizations/saritasa/releases/d48fcf1ca08c14e6009bf7d139527d6cc30cff0b/files-changed/?project=43
I get this
it doesn't look like real info or "changes" associated with SHA commit?
Also for django releases https://sentry.saritasa.rocks/organizations/saritasa/releases/70a81b36224a0a83d5a279938345ce0bee517cac/files-changed/?cursor=40%3A2%3A0&project=40
it shows all files in FILES CHANGED (127) - that feels like too much to me as well.
@kseniyashaydurova when I'm opening release info https://sentry.saritasa.rocks/organizations/saritasa/releases/d48fcf1ca08c14e6009bf7d139527d6cc30cff0b/files-changed/?project=43
I get this
it doesn't look like real info or "changes" associated with SHA commit?
It does, because we have not ignored .angular/cache/13.2.2
folder in https://github.com/saritasa-nest/saritasa-ci-experiments-frontend repo. Removed, check out new release - https://sentry.saritasa.rocks/organizations/saritasa/releases/5e36de83a68c165e0616ac397eb5a1a30bdf8577/commits/?project=43
Also for django releases https://sentry.saritasa.rocks/organizations/saritasa/releases/70a81b36224a0a83d5a279938345ce0bee517cac/files-changed/?cursor=40%3A2%3A0&project=40
it shows all files in FILES CHANGED (127) - that feels like too much to me as well.
It is ok too, Sentry releases works in the following scheme:
So in simple words for the very 1st release we will have a bunch of all commits, for the next ones - only commits between previous and new release.
@dmitry-mightydevops I added fixes you asked, please check this PR again
Add Sentry releases and sourcemaps (for frontend) functionality.
https://saritasa.atlassian.net/browse/SD-625 - add sourcemaps (frontend) https://saritasa.atlassian.net/browse/SD-624 - add releases (python and other apps)
Tested on
ci-experiments
on rocks EKSfrontend:
django:
kaniko-backend:
kaniko-frontend:
Firstly I thought that adding
build-static
step to kaniko is good (i.e. we haveinteresnee-frontend
project, which is built by kaniko), but then I found that it won't work ok, because basically we usekaniko
deployments for frontend in cases, when we need to install some extra dependency, like https://github.com/saritasa-nest/interesnee-frontend/blob/develop/ci/docker/Dockerfile#L9 (https://tekton.saritasa.rocks/#/namespaces/ci-experiments/pipelineruns/saritasa-ci-experiments-kaniko-frontend-dev-kaniko-build-pb778t)So basically we wouldn't be able to prepare
static
for kaniko frontend projects, because to do this we need original docker image deps, which are only inside docker image. Also we are not able to copy built static from docker image during build process, because we will have to run docker image for that and copy stuff from inner folder to tekton build folder.So I suggest to make
sentry-sourcemaps
upload logic forkaniko-frontend
directly inside Dockerfile (if it is needed), we just add here Sentry related secrets as env vars only.This is what happens when Sentry Token becomes invalid (when Sentry client leaves us). - https://tekton.saritasa.rocks/#/namespaces/ci-experiments/pipelineruns/saritasa-ci-experiments-django-backend-dev-build-pipeline-cf5rk?pipelineTask=sentry-release&step=release