search

getsentry / sentry

Developer-first error tracking and performance monitoring
https://sentry.io
Other
39.17k stars 4.2k forks source link

Releases are shared between projects #6649

Open mvantellingen opened 6 years ago

mvantellingen commented 6 years ago

We have various projects which all use semver. If we create a new release for a specific project which uses the same version number as another project (e.g. 1.1.0) then Sentry links the projects together. This is somewhat confusing, especially in the deployment mails since that will contain commits over multiple projects (and it can even leak commit detail to authors who should not have access to the other repo's)

I've narrowed it down to https://github.com/getsentry/sentry/blob/c220a42df1f74633598a7dff1c9c73a88a06f709/src/sentry/api/endpoints/organization_releases.py#L129 where a new version is created without taking the project into account.

mitsuhiko commented 6 years ago

That is intentional. You should prefix release names with the name of the project or similar. If you use a.dotted.name-VERSION the UI will strop the dotted path away. This is how mobile apps function for instance.

Wirone commented 5 years ago

@mitsuhiko Maybe this is intentional, but totally NOT intuitive. I was confused too, even reported it here: getsentry/sentry-cli#413.

IMO this behavior does not make sense. Besides cases described in linked issue:

It shouldn't be based on conventions (undocumented?), but on strict relations between entities (Environment → Project → Release → Deploy).

Right now we have many releases for many projects, many issues resolved with version binding, I don't know even how it could be "fixed" to achieve "intentional" behavior. Releases can't be renamed from UI and sentry-cli, I would need to delete them and add again? I would then lose fix release information in issues? Sigh...

Wirone commented 5 years ago

Ok, I've logged into Postgres and checked sentry_release data. There is project_id column, but every row has NULL there, which does not make sense too, since most of these versions were created in Gitlab CI via webhook (which is unique per project) so project information could/should be stored. Why it's not linked?

mitsuhiko commented 5 years ago

Releases are an organization level property and are not project bound as mentioned earlier. There is no API which would be able to create project specific releases.

Wirone commented 5 years ago

@mitsuhiko so why sentry_release table has project_id column and each project has unique release webhook? If release is organization level there should be organization_id (which now is implicitly bound through sentry_project).

IMO it all looks like WIP. I know (more or less) how it works now, but this issue (and the linked one) is about how we think it SHOULD work. Releases are project level in real life, not organization level (each project can have version with the same name, like 1.0.0, without need for adding project name to the version).

Please don't focus on how Sentry is designed right know, but consider arguments provided here and in getsentry/sentry-cli#413. Current flow is not intuitive and not documented, which leads to issues like @mvantellingen's or mine.

mitsuhiko commented 5 years ago

Releases can be associated with more than one project. For that reason we no longer use the singular project id column. However because they can be associated with more than one they are in a global namespace.

The product team decided this is what is least confusing. I would recommend leaving feedback on this in the user forums where it can be seen and discussed.

Wirone commented 5 years ago

@mitsuhiko ok, thanks for the feedback. I don't agree with this, but at least I know the reasoning.

Last thing, about mentioned a.dotted.name-VERSION:

trondhindenes commented 5 years ago

@mitsuhiko I have to add my vote to @Wirone 's frustrations here. I'm playing with different workarounds in my setup, and it just doesn't make any sense. Prefixing versions with the project name is suboptimal at best. Developers want to be able to search for issues related to release: 1.2.3, not release: wakk.wakk--1.2.3. Furthermore, this convention would require that the app knows its project name in addition to the DSN, which is an added complexity.

Again, please consider re-evaluating this design choice.

Wirone commented 5 years ago

@mitsuhiko Another issue with this approach is that project prefix must have at least 2 "dotted segments", so my.project-0.0.1 is valid, but myproject-0.0.1 is not. First one is displayed as Release 0.0.1 in Sentry's release view, second one is displayed as-is: Release myproject-0.0.1. This does not make sense at all. Also, I got error in the event:

image

which is weird because at any point I didn't send such value. This is dump just before $message = $this->encode($data); in Raven_Client::send():

array:15 [
  "server_name" => "f4b6a70be8d9"
  "project" => "2"
  "logger" => "console"
  "tags" => array:3 [
    "environment" => "local"
    "commit" => ""
    "symfony_version" => "4.2.5"
  ]
  "platform" => "php"
  "sdk" => array:2 [
    "name" => "sentry-php"
    "version" => "1.10.0"
  ]
  "transaction" => null
  "level" => "error"
  "extra" => array:2 [
    "context" => array:3 [
      "exception" => "Object RuntimeException"
      "command" => "foo:bar --ansi"
      "message" => "BOOM"
    ]
    "message" => "[console] Error thrown while running command "foo:bar --ansi". Message: "BOOM""
  ]
  "release" => "my.project-0.0.1"
  "exception" => array:1 [
    "values" => array:1 [
      0 => array:3 [
        "value" => "BOOM"
        "type" => "RuntimeException"
        "stacktrace" => array:1 [ ... ]
      ]
    ]
  ]
  "timestamp" => "2019-06-14T12:58:16Z"
  "event_id" => "af0f8e7c2c9a45bcbd15e76a5f5ae1b8"
  "contexts" => array:1 [
    "runtime" => array:2 [
      "version" => "7.2.8"
      "name" => "php"
    ]
  ]
  "breadcrumbs" => array:1 [
    0 => array:5 [
      "category" => "console"
      "message" => "Error thrown while running command "foo:bar --ansi". Message: "BOOM""
      "level" => "error"
      "timestamp" => 1560517096.2497
      "data" => array:3 [
        "exception" => "Object RuntimeException"
        "command" => "foo:bar --ansi"
        "message" => "BOOM"
      ]
    ]
  ]
]

Even if system (I mean software which uses Sentry as error tracker) is built with many components, each of them is probably versioned differently. They all are part of big "project". But in my opinion, there is no point in sending events from multiple components to one Sentry "project", since it means you will be mixing many releases (if you have component.a-1.0.0 and component.b-1.0.0 you will see 2 different 1.0.0 releases on the list while component's name is not displayed anywhere...). Also there is no point in versioning stack as a whole because then you must build/reconfigure each component every time you update at least one of them.

You have mentioned mobile apps, but why should you prefix version with mobile app's name when it would be much better if every app would send events to each own Sentry project? If so, only releases from each particular app would be listed in a project and while registering new release you should bind it to project. DSN for reporting issues and release webhook DO HAVE project's context built-in, why do not use it? I don't get it.

Sorry for bringing this issue up again, but I was going to clean up our projects and it's a mess. I don't have all releases in every project because if the same release (in X.Y.Zformat) exists in more than one project (and I mean Sentry project) it's listed in the one which was registered first and is not listed in the others (I can't use this version when resolving issue and so on). Maybe it's only 9.1.1 issue, because earlier it worked, I think so, but still... Renaming already registered versions (and related sentry_messagefiltervalue records), registering missing releases would be hard, so I wanted to reconfigure our projects (codebases) to use prefixed convention for release webhook and client but it's ugly (URL /sentry/myproject/releases/my.project-0.0.1/, really?), not intuitive and - as you can see above - buggy.

Please, please reconsider this approach. Or at least write down information why it's done like this and how to use it properly.

untitaker commented 5 years ago

@Wirone the error message you get is pretty bad, but what it tells you is just that your commit tag is empty and therefore it will be discarded

Wirone commented 5 years ago

@untitaker jeeez, now I see it's tags subfields' indexes or something like that. UX should be improved but it's somehow OK.

But the whole shared releases thing....naahhh :(

untitaker commented 5 years ago

I agree with you on both issues :)

gaurav5430 commented 4 years ago

That is intentional. You should prefix release names with the name of the project or similar. If you use a.dotted.name-VERSION the UI will strop the dotted path away. This is how mobile apps function for instance.

I don't understand the point about mobile apps versioning and naming ? How is it significant here?

If I have 2 mobile apps, one for iOS and the other for android, are you suggesting that as per sentry, I should attach the same release version to both of them, even though they send events to different projects ?

gaurav5430 commented 4 years ago

Releases can be associated with more than one project. For that reason we no longer use the singular project id column. However because they can be associated with more than one they are in a global namespace.

The product team decided this is what is least confusing. I would recommend leaving feedback on this in the user forums where it can be seen and discussed.

In what scenarios do we need to have releases associated with more than one project ?

BYK commented 4 years ago

Quoting @mitsuhiko from https://github.com/getsentry/sentry/issues/16664#issuecomment-715968176:

We investigated it again if we can make releases project specific and unfortunately that breaks a lot of usecases that customers currently have. I would leave this issue open as a meta issue since we're aware of the shortcomings and are investigating what options we have that do not break existing workflows.

Merging #16664 into this one and reopening as this issue has a lot more context and discussion.

AAllport commented 2 years ago

Sorry to poke an older issue, but, this doesn't seem significant to open a new one

In what scenarios do we need to have releases associated with more than one project?

We have an application split across 2 codebases. The two codebases are always released in tandem. We tag the releases with the same version across both codebases

Given they're separate repo's, we've got 2 projects in sentry for them, 2 DSN's. Logically, it feels like we should be able to associate the commits from both releases to the same release that's shared between the 2 projects (sentry-cli releases new -p project1 -p project2 $VERSION). We made this decision based on the following screenshot: https://docs.sentry.io/product/releases/ (https://docs.sentry.io/static/b11d2d382ea884ca68d83c5c45a24029/07a9c/release_index.png)

Is commit association not supported with multi-project versions? Is this a supported use case? Is this use-case covered under this issue? (If not, I'm happy to file a new issue)