Problem
PipelineRun, TaskRun, and other events currently define result states that producers are expected to populate. However, the specification does not clearly define the semantic meaning of each result value or how implementations should map their native execution states into the CDEvents result model.
Without clear guidance, different producers may map equivalent states differently, reducing interoperability across implementations.
For example:
- One system may map a validation failure to
error
- Another system may map the same condition to
failure
- Some systems expose concepts such as
skipped, ignored, or not executed which do not have obvious mappings
- Runtime failures and pre-execution failures may be represented differently depending on the implementation
Goal
Provide normative definitions for each PipelineRun and TaskRun result value and document recommended mappings from common execution outcomes.
The objective is to ensure that independent implementations produce consistent result states for equivalent conditions.
Open Questions
Failure vs Error
The distinction between failure and error is currently unclear.
Examples to consider:
- Assertion/test failure
- Validation failure before execution
- Runtime infrastructure failure
- Dependency resolution failure
- Timeout
- User cancellation
Should these map consistently across PipelineRuns and TaskRuns?
Skipped / Ignored States
Several systems expose concepts such as:
- skipped
- ignored
- not executed
- conditional execution not met
How should these states map into the existing result model?
Current implementations may map these to cancelled, but it is unclear whether that reflects the intended semantics.
Subject-Level Guidance
The same result values currently appear across multiple execution-oriented subjects.
Should result semantics be defined once at the execution-subject level and reused by:
- PipelineRun
- TaskRun
- Build
- TestSuiteRun
- TestCaseRun
to avoid duplicating definitions?
Expected Outcome
- Normative definitions for each result enum value
- Guidance for mapping common execution outcomes
- Consistent producer behavior across implementations
- Documentation suitable for inclusion in subject definitions and generated SDKs
Problem
PipelineRun, TaskRun, and other events currently define result states that producers are expected to populate. However, the specification does not clearly define the semantic meaning of each result value or how implementations should map their native execution states into the CDEvents result model.
Without clear guidance, different producers may map equivalent states differently, reducing interoperability across implementations.
For example:
errorfailureskipped,ignored, ornot executedwhich do not have obvious mappingsGoal
Provide normative definitions for each PipelineRun and TaskRun result value and document recommended mappings from common execution outcomes.
The objective is to ensure that independent implementations produce consistent result states for equivalent conditions.
Open Questions
Failure vs Error
The distinction between
failureanderroris currently unclear.Examples to consider:
Should these map consistently across PipelineRuns and TaskRuns?
Skipped / Ignored States
Several systems expose concepts such as:
How should these states map into the existing result model?
Current implementations may map these to
cancelled, but it is unclear whether that reflects the intended semantics.Subject-Level Guidance
The same result values currently appear across multiple execution-oriented subjects.
Should result semantics be defined once at the execution-subject level and reused by:
to avoid duplicating definitions?
Expected Outcome