-
Notifications
You must be signed in to change notification settings - Fork 50
ref(core): Replace release detection with Sentry CLI release detection #87
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,3 @@ | ||
| import { detectRelease } from "./detect-release"; | ||
| import { IncludeEntry as UserIncludeEntry, Options as UserOptions } from "./types"; | ||
|
|
||
| type RequiredInternalOptions = Required< | ||
|
|
@@ -81,7 +80,7 @@ export function normalizeUserOptions(userOptions: UserOptions): InternalOptions | |
| project: userOptions.project, | ||
| authToken: userOptions.authToken, | ||
| url: userOptions.url ?? "https://sentry.io/", | ||
| release: userOptions.release ?? detectRelease(), | ||
| release: userOptions.release ?? "", | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This seems odd but I want to keep There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would it hurt us to make it an optional property? If it is actually optional now, we should define it as such. (Same probably down the line for project, authToken etc. because they could be defined via config/env-vars now right?) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, we'd have to check for its definedness everywhere while right now we could be sure that it's defined. For env vars (whenever we bring them back) we can just assign them in our normalization step so we could still leave token, org, project, etc required. Generally, I'm thinking of moving our validation logic (which def needs to be refactored) into or before the final internal option conversion step so we can error before the plugin does anything. WDYT, does this sound reasonable? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
@lforst especially the config file is a valid point. Haven't thought about this when making the change here. So this means that, unless we want to read and parse the config file during normalization (which I don't want to do unless necessary), we have to refactor our internal options conversion to actually make these parameters (releaes, authtoken, etc) optional again... I'm gonna merge this PR to get some of the quick CLI replacements in and then tackle the options again. In the end this will change this line above |
||
| finalize: userOptions.finalize ?? true, | ||
| validate: userOptions.validate ?? false, | ||
| vcsRemote: userOptions.vcsRemote ?? "origin", | ||
|
|
||
This file was deleted.
Uh oh!
There was an error while loading. Please reload this page.
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.
In case we don't have a release (i.e. an empty string), we use the CLI to detect it automatically