feat(targetrollout): add targetRollout subject and queued/started/finished events - #328
Open
xibz wants to merge 2 commits into
Open
feat(targetrollout): add targetRollout subject and queued/started/finished events#328xibz wants to merge 2 commits into
xibz wants to merge 2 commits into
Conversation
…events Deployments today are only visible as a side effect of a service state change (service.deployed/service.upgraded), with no way to observe the orchestration act itself: when a rollout started, when it finished, or how long it took. This adds deployment as its own subject with the standard queued/started/finished lifecycle, giving DORA-style tooling an explicit deployment-duration/outcome fact independent of the resulting service entity. service.deployed/service.upgraded are unchanged; whether to deprecate them is a separate decision left for a follow-up once deployment.* has implementation experience. The original proposal also included a targetRollout subject to model fan-out to multiple destinations within one deployment; that's split into a separate follow-up PR pending more implementation experience. Signed-off-by: xibz <bjp@apple.com>
…ished events Follow-up to the deployment subject: targetRollout models a single destination within a deployment's environment (a region, canary slot, or named blue/green slot), giving environment a first-class inbound link to what was rolled out into it, and giving consumers per- destination outcome/failureType detail when a deployment fans out to more than one target. This mirrors the pipelineRun/taskRun split already in the spec: a parent orchestration entity (deployment/pipelineRun) fans out to child execution units (targetRollout/taskRun), each with the standard queued/started/finished lifecycle. Stacked on the deployment subject (see the deployment branch/PR) since targetRollout's deploymentId reference and docs build on it. Signed-off-by: xibz <bjp@apple.com>
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
1 participant
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.
Follow-up to #319 (
deployment.queued/started/finished), per @afrittoli's review: landingdeploymenton its own first, withtargetRolloutproposed separately here now that there's a concrete use case and one open PR of implementation experience to point to.What this adds
targetRollout— a specific destination within adeployment's environment (a region, canary slot, or named blue/green slot) — with the standardqueued/started/finishedlifecycle, adeploymentIdback-reference to its parentdeployment, andfailureTypeonfinishedfor per-destination failure detail.Why this isn't a new execution model
The concern raised on #319 was that giving
targetRolloutits own independent lifecycle "encodes one execution model." But this is the same shape the spec already has forpipelineRun/taskRun: a parent orchestration entity fans out to child execution units, each with its ownqueued/started/finished.targetRolloutunderdeploymentis that same pattern, not a new one. A producer that genuinely fans a deployment out to multiple destinations already has to track per-destination timing to coordinate the rollout in the first place — this just gives that internal fact a standard external shape. A producer that deploys to exactly one destination, or that calls a single atomic multi-region API with no per-destination visibility, simply doesn't emittargetRollout— same as any other optional CDEvents subject.targetRolloutalso givesenvironmenta first-class inbound link to what was deployed into it — today the only way to find out what's running in an environment is to scanserviceevents and filter oncontent.environment.id, a reference that points the wrong way for that query.Depends on #319 — this diff will be just the
targetRolloutadditions once that merges.Submitter Checklist
As the author of this PR, please check off the items in this checklist: