This repository has been archived by the owner on Aug 14, 2024. It is now read-only.
-
-
Notifications
You must be signed in to change notification settings - Fork 224
feat: add Linux distributions to the os context #1227
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
@supervacuus is attempting to deploy a commit to the Sentry Team on Vercel. A member of the Team first needs to authorize it. |
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
This was referenced Apr 17, 2024
Dav1dde
reviewed
Apr 18, 2024
Dav1dde
approved these changes
Apr 19, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for putting all the effort in, I'd just link to some source (you think is best) for the distribution names 👍
Also mention the /etc/os-release keys and how they map to the ones in the distribution object.
narsaynorath
pushed a commit
to getsentry/sentry
that referenced
this pull request
May 17, 2024
Users of the Native SDK also want to search for the Linux distributions their events came from: getsentry/sentry-native#943 The corresponding PRs to * develop docs: getsentry/develop#1227 * relay: getsentry/relay#3443 * Native SDK: getsentry/sentry-native#963
cmanallen
pushed a commit
to getsentry/sentry
that referenced
this pull request
May 21, 2024
Users of the Native SDK also want to search for the Linux distributions their events came from: getsentry/sentry-native#943 The corresponding PRs to * develop docs: getsentry/develop#1227 * relay: getsentry/relay#3443 * Native SDK: getsentry/sentry-native#963
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Users of the Native SDK would prefer to identify and search for Linux distributions their events come from: getsentry/sentry-native#943.
After a preliminary implementation (getsentry/sentry-native#963 and getsentry/relay#3443), I think it is time to nail down the specification of the context attributes.
I consider the current naming of the attributes to be preliminary. I didn't want to force the naming scheme from
/etc/os-release
onto the attributes here (but maybe we should?), and the selection of the attributes is also a bit arbitrary.Only
name
andversion
make sense as indexable entries because the support of other attributes varies wildly between distributions (not only in availability but sometimes also in meaning). Most users probably want to know where issues occur on a specific distribution version rather than necessarily seeing the URL of a distro's issue tracker.Nonetheless, we could add all other attributes we find in
/etc/os-release
(in which case I would use the original names. The current mapping is:name
ID
NAME
attribute is not stable and changes in some distros between versionsversion
VERSION_ID
VERSION
attribute often includes version aliasespretty_name
PRETTY_NAME
I am also unsure whether exposing
distribution
as an object rather than prefixed flat attributes is preferred. All these decisions are easy to revert right now, whereas they can be painful once events are out there.Cc: @kahest