Conformance Policy around Custom Task Run

[XinruZhang]

Creating this issue to propose:

1. Define conformance policy for Custom Task API, including
   • the requirement (REQUIRED|RECOMMENDED|OPTIONAL) of each field.
2. Define that to what extent PipelineRun Controller relies on each field
   • for example, Pipeline Controller can only rely on required fields, must not rely on optional fields etc.
3. Develop a conformacne test suite
   • to enforce that Custom Task controller conforms to the requirement of each field.

The motivation behind this issue is: nowadays. we expect customers to implement something but we have no way to enforce that, this has caused a lot of inconsistency between the design, the documentation and the actual implementation in Custom Task Run. Including but not limited to: #5653, #5582, #5393

Let me get the ball rolling, feel free to leave comments!

1. Required Fields
   • TypeMeta
   • Spec.Status to support pipeline-level timeouts
   • Status.Conditions: only mark the CustomRun as done when it's really done (all retry attempts have been exhausted)
2. Pipeline Controller should only rely on required fields without caring about how optional fields are implemented.
3. Develope a conformance test suite to ensure a custom taks controller conform to the policy we defined.

Taking retries and timeout functionality as example, custom task controller should only report the custom task as done (Reason!="" && Reason!=UNKNOWN) after exhausting all retries. And Pipeline Controller only relies on status report to decide the current status of a Run. (removing the dependence on len(retriesStatus))

cc @tektoncd/core-collaborators

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[vdemeester]

/lifecycle frozen
/area roadmap