Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SENTRY_TAGS environment variable doesn't work after upgrading from 1.7.30 to 3.0.0 #981

Closed
5 of 27 tasks
bbednarek opened this issue Oct 14, 2020 · 4 comments · Fixed by #1066
Closed
5 of 27 tasks
Assignees
Labels

Comments

@bbednarek
Copy link

bbednarek commented Oct 14, 2020

Platform:

  • Android -> If yes, which Device API (and compileSdkVersion/targetSdkVersion/Build tools) version?
  • Java -> If yes, which Java (and sourceCompatibility/targetCompatibility) version?
    targetCompatibility = sourceCompatibility = 14
  • Kotlin -> If yes, which Kotlin (and jvmTarget) version?
  • NDK -> If yes, which NDK/CMake version?
  • React-Native -> If yes, which version?
  • Timber -> If yes, which version?
  • Log4j -> If yes, which version?
  • Logback -> If yes, which version? 1.2.3
  • Spring -> If yes, which version? 2.3.4.RELEASE

IDE:

  • Android Studio -> If yes, which version?
  • IntelliJ -> If yes, which version? 2020.2.2
  • Other -> If yes, which one?

Build system:

  • Gradle -> If yes, which version?
  • Buck -> If yes, which version?
  • Bazel -> If yes, which version?
  • Maven -> If yes, which version?
  • Other -> If yes, which one?

Android Gradle Plugin:

  • Yes -> If yes, which version?
  • No

Sentry Android Gradle Plugin:

  • Yes -> If yes, which version?
  • No

Proguard/R8:

  • Enabled
  • Disabled

Platform installed with:

  • JCenter
  • Bintray
  • Maven Central
  • Manually

The version of the SDK:
3.0.0


I have the following issue:

We used to set following environment variable

"SENTRY_TAGS": "service:%s" %(self.name),

and tags were available in sentry
Screenshot 2020-10-14 at 17 10 06

and after upgrading to version 3.0.0 this variable does't work any more.
Screenshot 2020-10-14 at 17 11 43

Steps to reproduce:
Upgrade

            dependency 'io.sentry:sentry-logback:1.7.30'

to

            dependency 'io.sentry:sentry-logback:3.0.0'

Actual result:
Tags are gone

Expected result:
Tags are present

@bruno-garcia
Copy link
Member

Thank you for giving 3.x a try! We'll discuss this internally and get back to you soon.

@chrsblck
Copy link

I'm having some related issues with external config on v3.1.0 as well. I can open another issue if you'd like, just let me know.

  1. SENTRY_IN_APP_INCLUDES environment variable doesn't get applied to config (even when all configs are done via Env. variables)

  2. If I combine application.yml with environment variables, all the config in application.yml is lost.

For example, if I set SENTRY_DSN=... and:

sentry:
  environment: Dev

I will only see the Sentry DSN configured, there will be no Sentry Env configured.

@bruno-garcia
Copy link
Member

SENTRY_IN_APP_INCLUDES isn't included in the new SDK. The are some environment variables whch is default in all Sentry SDKs like SENTRY_DSN, SENTRY_RELEASE SENTRY_ENVIRONMENT which takes presedence over any value set via configuration or programatically, but other than that values can be configured either programatically: Sentry.init(o -> o.inAppInclude(..) or when using spring, via the application.properties|yaml.

We should make it clear on the docs that the old environment variables are not necessarily supported, it depends on what it was.

If values set via env var are not considered when you set stuff via configuration, that would be a problem. Would you mind raising an issue for that so we can investigate?

@chrsblck
Copy link

We should make it clear on the docs that the old environment variables are not necessarily supported, it depends on what it was.

Yeah, that would be nice if it were documented which env. vars were supported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants