Repository navigation
feat(integrations): Add SCM milestone lifecycle metrics - #129165
Closed
giovanni-guidini wants to merge 1 commit into
Closed
giovanni-guidini wants to merge 1 commit into
giovanni-guidini wants to merge 1 commit into
Conversation
Separate internal SCM operations from customer-facing feature outcomes while preserving provider and parent interaction dimensions. Refs SCM-304
Contributor
Author
|
Closing this foundation PR because the design was simplified: complete feature outcomes remain on |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Introduces an SCM milestone lifecycle metric family for internal operations, preserving the existing provider and interaction dimensions while adding a required parent interaction so customer-facing feature SLOs can remain authoritative outcomes. This is the base of a two-PR stack for SCM-304; #129169 migrates stack-trace and CODEOWNERS file checks.
Why do I want this?
We defined a set of features that are considered relevant for SCM (or are SCM-powered) and are reviewing the metrics we have around those.
The code already defined this lifecycle thing, but some of the operations captured as a full lifecycle aren't "features" but parts of features / a step.
So here we're introducing this hierarchical split: features are
integration.slo.*metrics while relevant parts of features (that get their own lifecycle) are moved to milestones.