-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
chore(integrations): installation pipeline step metrics #78588
base: master
Are you sure you want to change the base?
Conversation
bfdff76
to
b6ca552
Compare
Codecov ReportAttention: Patch coverage is ✅ All tests successful. No failed tests found.
Additional details and impacted files@@ Coverage Diff @@
## master #78588 +/- ##
==========================================
+ Coverage 78.21% 78.23% +0.01%
==========================================
Files 7104 7102 -2
Lines 312933 313200 +267
Branches 51102 51147 +45
==========================================
+ Hits 244773 245034 +261
- Misses 61797 61803 +6
Partials 6363 6363 |
lifecycle.add_extra( | ||
"organization_id", | ||
self.active_organization.organization.id if self.active_organization else None, | ||
) |
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.
Not super applicable for this PR I guess, but would it make sense for us to fold extra data like this into the record_event(...).capture()
call? Are there cases when we'd want to conditionally add data like this vs just specifying it once at the beginning of the context manager block?
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.
this data is not present at the beginning of the block so i'm adding it in here
integration_pending_deletion_exists = False | ||
if self.active_organization: | ||
# We want to wait until the scheduled deletions finish or else the | ||
# post install to migrate repos do not work. | ||
integration_pending_deletion_exists = OrganizationIntegration.objects.filter( | ||
integration__provider=GitHubIntegrationProvider.key, | ||
organization_id=self.active_organization.organization.id, | ||
status=ObjectStatus.PENDING_DELETION, | ||
).exists() |
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.
The diffs are a bit weird for this change. Is the only difference the context manager and record_failure
lifecycle calls?
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.
yes unfortunately the indentation makes it looks like all of this is new. only the context manager, record_failure
, add_extra
calls are new
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.
It's crazy 😭 I'm surprised github haven't figured out indent yet.
@@ -746,6 +763,8 @@ def test_github_prevent_install_until_pending_deletion_is_complete(self): | |||
in resp.content | |||
) | |||
|
|||
self.assert_failure_metric(mock_record, GitHubInstallationError.PENDING_DELETION) |
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.
Love to see assertions for this
PENDING_DELETION = "GitHub installation pending deletion." | ||
INSTALLATION_EXISTS = "Github installed on another Sentry organization." |
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.
nit: Are these user facing? If so can we make sure they're sentences with verbs?
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.
these come up in a toaster
integration_pending_deletion_exists = False | ||
if self.active_organization: | ||
# We want to wait until the scheduled deletions finish or else the | ||
# post install to migrate repos do not work. | ||
integration_pending_deletion_exists = OrganizationIntegration.objects.filter( | ||
integration__provider=GitHubIntegrationProvider.key, | ||
organization_id=self.active_organization.organization.id, | ||
status=ObjectStatus.PENDING_DELETION, | ||
).exists() |
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.
It's crazy 😭 I'm surprised github haven't figured out indent yet.
|
||
# At this point, we are past the GitHub "authorize" step | ||
if request.GET.get("state") != pipeline.signature: | ||
lifecycle.record_failure({"failure_reason": GitHubInstallationError.INVALID_STATE}) |
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.
What does invalid state mean? Like we're in step 3 without doing step 2 of the pipeline?
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.
i'm not exactly sure... i'm just reusing the definition from before
IDENTITY_PROVIDER = "IDENTITY_PROVIDER" | ||
|
||
# GitHub | ||
OAUTH_LOGIN = "OAUTH_LOGIN" |
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.
Should these have integration name in them? Are they meant to be shared?
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.
we already pass in the integration name when initializing the metric class
Introduces
IntegrationPipelineViewEvent
as anEventLifecycleMetric
that captures instances of a user going through an integration pipeline view (step). The idea is to wrap eachdispatch
method of anIntegrationPipelineView
class to track how often each step is completed after entering the step.If failures occur, the newly modified
record_failure
function can also accept extra data to log, which should help with debugging when customers encounter issues. We currently do not have any logging in the event of a failure during integration installation.I've added the context manager for GitHub installation in this PR to give an example of how
IntegrationPipelineViewEvent
would be used.