TEP-0077: Partial pipeline execute - amended - proposal.

teps/0077-pipeline-partial-execution.md

@@ -90,36 +90,35 @@ Together these will bring in the ability to resume/retry a failed `PipelineRun`
 
 ## Proposal
 
-#### Requesting API Changes
-1. Add `resumeFrom` under `PipelineRun.spec`. It has following fields: 
-   - `resumeFrom.name` which is the name of previously run `PipelineRun`.
-   - `resumeFrom.enableTasks` accepts an array of task names under it.
+### Requesting API Changes
+1. Add `pipelineRunRef` under `PipelineRun.spec`. It has following fields: 
+   - `pipelineRunRef.name` which is the name of previously run `PipelineRun`.
+   - `pipelineRunRef.enableTasks` accepts an array of task names under it.
 2. Add `disableTasks` under `PipelineRun.spec`, which accepts an array
-    of task name and their result definitions.
+    of task name.
    - `name`: Name of the task to be disabled.
-        - `results`: Pre-populate results for the disabled task.
 
-Q. Why do we need `resumeFrom` when we have `disableTasks`? 
+Q. Why do we need `pipelineRunRef` when we have `disableTasks`? 
 
 `disableTasks` can be used to explicitly disable tasks that a user 
-do not wish to run and `resumeFrom` tekton controller automatically
-figures out the tasks failed and unfinished, because it knows the
-DAG. For the end user, it can be difficult to figure out the DAG and
-prepare the accurate execution plan for the next pipeline run.
+do not wish to run. On the other hand, in `pipelineRunRef` tekton controller
+automatically figures out the tasks failed and unfinished, because it knows the
+DAG. For the end user, it can be difficult to figure out the DAG and prepare
+the accurate execution plan for the next pipeline run.
 
-Both, `resumeFrom` and `disableTasks` are optional fields. See examples
+Both, `pipelineRunRef` and `disableTasks` are optional fields. See examples
 1 and 2 below.
 
-#### Semantics of execution.
+### Semantics of execution.
 
-- `resumeFrom` : resumeFrom references a previous pipelineRun and by default
-selects all the failed and unfinished tasks eligible for retrying/resuming.
-It references results of completed tasks from previous run, unless
-overridden by `disableTasks` section.
+- `pipelineRunRef` : pipelineRunRef references a previous pipelineRun and by default
+    selects all the failed and unfinished tasks eligible for retrying/resuming.
+    It references results of completed tasks from previous run.
 
-- `resumeFrom.enableTasks`: If a task was successful in previous run, but
-it is required by the current run, this section can be used to explicitly
-enable it.
+- `pipelineRunRef.enableTasks`: If a task was successful in previous run, but
+    it is required by the current run, this section can be used to explicitly
+    enable it. For example, a task may perform some initialization for the
+    other tasks in `PipelineRun`.
 
 **Case: disabled task exists somewhere in the middle of DAG execution.**
 
@@ -135,16 +134,17 @@ G   B --> E
 ```
 
 1. 
-  - Previous Run stats:
+  - Previous Run stats from `prev-pipeline-run` :
     - Successful Tasks: A 
     - Failed Tasks: F, B
     - Not yet started tasks: D, E, G, C
-  - Current Run:
-      - Disabled task: B
-      - To be executed: F, D, E, G, C
+  - Current Run: `new-pipeline-run`
+      - Disabled task: B, G
+      - To be executed: F, D, C
 
-Since task B is disabled, task E will use its pre-set result.
-Even if we disable G, F is still retried in the current Run.
+Since task B is disabled, task E will also be disabled as it depends on B.
+
+We have disabled G, but F is still retried in the current Run i.e. `new-pipeline-run`
 
 #### Examples
 
@@ -156,26 +156,20 @@ kind: PipelineRun
 metadata:
   name: new-pipeline-run
 spec:
-  # resumeFrom references a previous pipelineRun and by default selects
-  # all the failed and unfinished tasks eligible for retrying/resuming.
-  # It references results of completed tasks from previous run, unless
-  # overridden by disableTasks section.
-  resumeFrom:
+  # pipelineRunRef references a previous pipelineRun and by default selects
+  # all the "failed" and "unfinished" tasks eligible for retrying/resuming.
+  # It references results of completed tasks from previous run.
+  pipelineRunRef:
     name: prev-pipeline-run
     # Enable tasks section can be used to enable those tasks which were
     # successful in previous run. e.g. an init task.
     enableTasks:
-      - name: init-task-name
+      - name: A
   # One of the failed task is disabled by disableTasks section, for some
   # reason we want it skipped and the expected results has been hard coded.
   disableTasks:
-    - name: task-name
-      # option to pre-populate the values of disabled task's results.
-      results: 
-        - name: result1-name
-          value: some-val
-        - name: result2-name
-          value: some-val2
+    - name: B
+    - name: G
   serviceAccountName: 'default'
   # Some tasks needs cleaning of workspaces, this can be done here.
   # e.g. one could override a workspace by specifying the name.
@@ -189,6 +183,8 @@ spec:
       name: some-ref
 ```
 
+Above example will run tasks: A, F, D, C
+
 2. Partial execution of a pipeline.
 
 ```yaml
@@ -200,27 +196,21 @@ spec:
   pipelineRef:
     name: a-pipeline
   disableTasks:
-    - name: task-name
-      # optionally pre-populate the values of disabled task's results.
-      results: 
-        - name: result1-name
-          value: some-val
-        - name: result2-name
-          value: some-val2
-    - name: task-name-other
-      results:
-        - name: result1-name
-          value: some-val
-        - name: result2-name
-          value: some-val2
+    - name: B
+    # the task `B` is disabled for the current execution and everything
+    # that depends on it.
+    - name: G
 ```
 
-### Notes/Caveats (optional)
+Above example will run tasks: A, F, D, C
 
-Q. Can we provide an option to disable a task and all the that depend on it?
+### Notes/Caveats (optional)
 
-e.g. disable task with a flag e.g. `cascade: true` or `disableDependents: true`.
+Q. Can we provide an option to disable a task but not all the that depend on it?
 
+e.g. disable task with a flag e.g. `cascade: false` or `disableDependents: false`.
+Also provide an option for hard-conding the results.
+My preference is this can be work for future TEP.
 
 ### Risks and Mitigations