Update helm charts for Sentry configuration

[ewelinagr]

Implements RB-152

Some of the components have been enhanced with Sentry monitoring. This PR:

• Updates the helm charts to accept the Sentry-specific helm values
• Maps those helm values to ENV VARS

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching charts/*/values.yaml:

• Is the PR adding a new container? Please reviewer, add it to the models (internal process)
• Is the PR adding a new parameter? Please, ensure it’s documented in the README.md

This is an automatically generated QA checklist based on modified files.

[keyvaann]

Could you please explain why these should be configurable?

[ewelinagr]

Those two don't need to be configurable, I made it that way just to give more flexibility in how the service names are displayed in Sentry as an extra option. I can remove that, if this is problematic or just not needed.

[keyvaann]

It's not problematic and in general it's good to have the flexibility. However this adds a bit of complexity to the charts and since I haven't used the Sentry interface I don't know how much benefit this brings. You can decide on this.

[ewelinagr]

Ok, thanks for clarification, I removed the conditional values for now.

[keyvaann]

Thanks, I think in this case we can use existing chart variables such as {{ include "catalog-server.name" . }}, {{ include "catalog-server.chart" . }}, {{ .Release.Name }}, {{ .Release.Service }} instead of creating new functions in _helpers.tpl.

[ewelinagr]

@pvannierop, before I change something here, could you double-check if this is what you had in mind for those 2 variables (sentryName, sentryRelease), or you think it is better to use a different combination of variables for sentryName, e.g. instead of the fullName defined above, fix it to some string containing .Chart.Name .Chart.Version or .Release.Name

[pvannierop]

Looks good. Nice work! One small thing is that would it be more efficient to replace package definitions like:

    packages: "org.radarbase.oura,org.radarbase.connect"

to more simple

    packages: "org.radarbase"

? So to basically trace from org.radarbase.*?

[pvannierop]

Is this package string correct? The comparisons part looks strange to me.

[ewelinagr]

yes,this is the one that is packaged under comparisons:
radar-expression-lang/src/main/kotlin/comparisons/Library.kt
If not needed, I can remove it

[pvannierop]

@ewelinagr Did you perhaps miss this comment?

[ewelinagr]

Looks good. Nice work! One small thing is that would it be more efficient to replace package definitions like:

    packages: "org.radarbase.oura,org.radarbase.connect"

to more simple

    packages: "org.radarbase"

? So to basically trace from org.radarbase.*?

Yes, it could be simplified to org.radarabase, if we want to be more generic and always include all with that prefix