Repository navigation
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>
| { | ||
| "$id": "cdevents/_defs/targetrollout", | ||
| "term": "TargetRollout", | ||
| "definition": "A TargetRollout is a specific destination within an environment to which a release unit may be deployed and made available. A TargetRollout is always contained within an environment. Multiple TargetRollouts may exist within a single environment.", |
There was a problem hiding this comment.
I'm confused here. I thought a TargetRollout was an activity that can be queued, started and finished . In here it is defined as a destination, which seems inconsistent. Can you clarify?
There was a problem hiding this comment.
Good catch! The definition was wrong, not the model. A targetRollout is the activity: rolling a deployment out to one target within an environment. The destination itself is already captured by target and environment. I've reworded the definition, examples, and counterExamples accordingly (and moved "a canary slot" to counterExamples, since that's the place, not the rollout). I'd rather not rename to targetRolloutRun: unlike pipeline, there's no static "rollout" definition entity for the Run to distinguish from, "rollout", like "deployment", already names the act.
| "required": [ | ||
| "name", | ||
| "target", | ||
| "environment", | ||
| "artifactId" | ||
| ] |
There was a problem hiding this comment.
I was expecting the deploymentId to be required. Could you describe a use case where it would not be set?
| "required": [ | ||
| "name", | ||
| "target", | ||
| "environment", | ||
| "artifactId", | ||
| "outcome" |
There was a problem hiding this comment.
NIT: this could be:
"required": ["name", "target", "environment", "artifactId", "outcome"],
"if": { "properties": { "outcome": { "const": "failure" } } },
"then": { "required": ["failureType"] },
"else": { "not": { "required": ["failureType"] } }to enforce that failureType must be there in case of failure and must not be there in case of success.
That said, we don't have that in other schemas, although it would be nice to add.
| "id": "test123" | ||
| }, | ||
| "artifactId": "pkg:oci/myapp@sha256%3A0b31b1c02ff458ad9b7b81cbdf8f028bd54699fa151f221d1e8de6817db93427", | ||
| "deploymentId": "mySubject123" |
There was a problem hiding this comment.
Shouldn't this be different from the subject.id? I think having the same value is confusing.
- Redefine targetRollout as the act of deploying a release unit to a single destination, not the destination itself. The destination is already identified by the target and environment fields, and the queued/started/finished lifecycle only makes sense for an activity. Examples and counterExamples updated to match. - Make deploymentId required on queued/started/finished: a target rollout is always part of a deployment. - Give the parent deployment a distinct id in the targetRollout conformance examples so it no longer reads as the subject itself. Signed-off-by: xibz <bjp@apple.com>
|
@afrittoli - thanks Andreaa! Can you take a look again? |
2 participants
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: