jicofo, jigasi, jvb: fix SENTRY_DSN not being read

[DanielMcAssey]

This should fix #1655

[saghul]

Thank you!

[krombel]

There are several flaws in this PR apparently...

1. It is now not possible anymore to have dedicated SENTRY_DSNs for the different containers
2. Why all services now default to JICOFO_SENTRY_DSN - although the service is jigasi or jvb...

[saghul]

You are right, I pulled the trigger too quick 😅

Indeed we should keep thedifferent DSNs a possibility.

[DanielMcAssey]

There are several flaws in this PR apparently...

1. It is now not possible anymore to have dedicated SENTRY_DSNs for the different containers
2. Why all services now default to JICOFO_SENTRY_DSN - although the service is jigasi or jvb...

For 1, its hasn't been possible to have separate SENTRY_DSN with the previous configuration. This just solves the issue of actually enabling SENTRY_DSN

For 2, the reason it defaults to JICOFO_SENTRY_DSN is for backwards compatibility as referenced in #342 (comment)

[saghul]

For 1, its hasn't been possible to have separate SENTRY_DSN with the previous configuration. This just solves the issue of actually enabling SENTRY_DSN

The intent was there. If SENTRY_DSN wasn't set, it was set to a default based on the service, else to 0.

[DanielMcAssey]

So I can update the PR to make individual SENTRY_DSNs, but it would break backwards compat with JICOFO_SENTRY_DSN as it would involve remapping env variables in docker-compose.yaml

Ultimately the Sentry library is looking for the SENTRY_DSN environment variable, so either we export it manually during a run command, or remap in docker-compose, I don't mind doing either.

Ignore me, opened a new PR, kept my previous comment for posterity