+
-
+
Tasks and Pipelines and Pipeline-as-code](#versioned-s-and-s-and-pipeline-as-code)
+ - [Versioned Tasks and Pipelines and Pipeline-as-code](#versioned-tasks-and-pipelines-and-pipeline-as-code)
- [Shipping catalog resources as OCI images](#shipping-catalog-resources-as-oci-images)
- [Tooling](#tooling)
- [Risks and Mitigations](#risks-and-mitigations)
diff --git a/teps/0007-conditions-beta.md b/teps/0007-conditions-beta.md
index e57136604..45b6feb17 100644
--- a/teps/0007-conditions-beta.md
+++ b/teps/0007-conditions-beta.md
@@ -40,7 +40,7 @@ tags, and then generate with `hack/update-toc.sh`.
- [Efficiency](#efficiency-2)
- [CelRun Custom Task](#celrun-custom-task)
- [Expression Language Interceptor](#expression-language-interceptor)
- - [Status](#status-2)
+ - [Status](#status)
- [Minimal Skipped](#minimal-skipped)
- [ConditionSucceeded](#conditionsucceeded)
- [ConditionSkipped](#conditionskipped)
@@ -658,7 +658,7 @@ To make it flexible, similarly to Triggers which uses language interceptors that
### Status
-#### Minimal Skipped
+#### Minimal Skipped
Add `Skipped Tasks` section to the `PipelineRunStatus` that contains a list of `SkippedTasks` that contains a `Name` field which has the `PipelineTaskName`. The `WhenExpressions` that made the `Task` skipped can be found in the `PipelineSpec`, the `Parameter` variables used can be found in the `PipelineSpec` and the `Results` used from previous `Tasks` can be found in the relevant `TaskRun`. It may be more work for users to reverse-engineer to identify why a `Task` was skipped, but gives us the benefit of significantly reducing the `PipelineRunStatus` compared to what we currently have with `Conditions`.
diff --git a/teps/0008-support-knative-service-for-triggers-eventlistener-pod.md b/teps/0008-support-knative-service-for-triggers-eventlistener-pod.md
index 6643c0540..2df231504 100644
--- a/teps/0008-support-knative-service-for-triggers-eventlistener-pod.md
+++ b/teps/0008-support-knative-service-for-triggers-eventlistener-pod.md
@@ -25,7 +25,7 @@ status: implemented
- [Usage examples](#usage-examples)
- [Default EventListener yaml](#default-eventlistener-yaml)
- [Kubernetes Based](#kubernetes-based)
- - [Knative Service OR any CRD](#knative-service-)
+ - [Knative Service OR any CRD](#knative-service-or-any-crd)
- [Design Details](#design-details)
- [Contract](#contract)
- [Spec](#spec)
@@ -142,7 +142,7 @@ spec:
name: pipeline-template
```
-#### Kubernetes Based
+#### Kubernetes Based
This is exactly the same whatever we have right now with default.
The reason to move `serviceAccountName`, `podTemplate`,
to `kubernetesResource` field is because those are part of [WithPodSpec{}](https://github.com/knative/pkg/blob/master/apis/duck/v1/podspec_types.go#L49) duck type
diff --git a/teps/0010-optional-workspaces.md b/teps/0010-optional-workspaces.md
index 5d506cb61..10ecf2765 100644
--- a/teps/0010-optional-workspaces.md
+++ b/teps/0010-optional-workspaces.md
@@ -28,7 +28,7 @@ status: implemented
- [Story 6](#story-6)
- [Risks and Mitigations](#risks-and-mitigations)
- [Design Details](#design-details)
- - [Example: git-clone Catalog Task](#example--catalog-task)
+ - [Example: git-clone Catalog Task](#example-git-clone-catalog-task)
- [Test Plan](#test-plan)
- [Drawbacks](#drawbacks)
- [Alternatives](#alternatives)
diff --git a/teps/0014-step-timeout.md b/teps/0014-step-timeout.md
index 623e1d28b..c6726e8ea 100644
--- a/teps/0014-step-timeout.md
+++ b/teps/0014-step-timeout.md
@@ -19,7 +19,7 @@ status: implemented
- [Risks and Mitigations](#risks-and-mitigations)
- [Design Details](#design-details)
- [Caveats](#caveats)
- - [Resolution of a Step Timeout](#resolution-of-a--timeout)
+ - [Resolution of a Step Timeout](#resolution-of-a-step-timeout)
- [Test Plan](#test-plan)
- [References](#references)
diff --git a/teps/0022-trigger-immutable-input.md b/teps/0022-trigger-immutable-input.md
index ec2ef8712..c3ca00ff7 100644
--- a/teps/0022-trigger-immutable-input.md
+++ b/teps/0022-trigger-immutable-input.md
@@ -25,7 +25,7 @@ status: implemented
- [Drawbacks](#drawbacks)
- [Payload redaction](#payload-redaction)
- [Alternatives](#alternatives)
- - [Introduce input field](#introduce--field)
+ - [Introduce input field](#introduce-input-field)
- [Keep mutable behavior](#keep-mutable-behavior)
- [Upgrade and Migration Strategy](#upgrade-and-migration-strategy)
- [Implementation PRs](#implementation-prs)
diff --git a/teps/0024-embedded-trigger-templates.md b/teps/0024-embedded-trigger-templates.md
index 29ac88ba9..d7c334d67 100644
--- a/teps/0024-embedded-trigger-templates.md
+++ b/teps/0024-embedded-trigger-templates.md
@@ -87,7 +87,7 @@ There are two changes proposed to the Trigger spec:
ref: "my-tt"
```
-## Upgrade & Migration Strategy
+## Upgrade & Migration Strategy
For the `name` to `ref` change, we'll make the upgrade process backwards
compatible:
@@ -100,7 +100,7 @@ compatible:
1. In a future release, we'll remove the `name` field from the spec.
-## References
+## References
1. GitHub issue: https://github.com/tektoncd/triggers/issues/616
diff --git a/teps/0025-hermekton.md b/teps/0025-hermekton.md
index 2dfe0e1f9..7cefa42f8 100644
--- a/teps/0025-hermekton.md
+++ b/teps/0025-hermekton.md
@@ -98,14 +98,14 @@ This currently holds just a single bool, but could be expanded in the future.
See [this rationale](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#primitive-types) in the k8s API style guide for why we introduce a new type.
-| Object | Field | Description |
-| --- | --- | --- |
-| Task | spec.steps[*].ExecutionMode | Whether or not Steps of this Task should happen hermetically. This can be overridden on the TaskRun |
-| Task | spec.ExecutionMode | Whether or not TaskRuns of this Task should happen hermetically. This can be overridden on the TaskRun |
-| TaskRun | spec.ExecutionMode | Whether or not this TaskRun will be run hermetically. This can be used to override the value on the Task |
-| Pipeline | spec.ExecutionMode |Whether or not the **entire** pipeline should run hermetically. This can be overridden on the PipelineRun |
-| PipelineRun | spec.ExecutionMode | Whether or not the **entire** PipelineRun will be run hermetically. This can be used to override the default value on the Pipeline, but can be overridden for a specific TaskRun below.
-| PipelineRun | spec.TaskRunSpecs.ExecutionMode | Whether or not this specific TaskRrun should be run hermetically during a PipelineRun. This overrides the Task, Pipeline and PipelineRun defaults. |
+| Object | Field | Description |
+|-------------|---------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Task | spec.steps[*].ExecutionMode | Whether or not Steps of this Task should happen hermetically. This can be overridden on the TaskRun |
+| Task | spec.ExecutionMode | Whether or not TaskRuns of this Task should happen hermetically. This can be overridden on the TaskRun |
+| TaskRun | spec.ExecutionMode | Whether or not this TaskRun will be run hermetically. This can be used to override the value on the Task |
+| Pipeline | spec.ExecutionMode | Whether or not the **entire** pipeline should run hermetically. This can be overridden on the PipelineRun |
+| PipelineRun | spec.ExecutionMode | Whether or not the **entire** PipelineRun will be run hermetically. This can be used to override the default value on the Pipeline, but can be overridden for a specific TaskRun below. |
+| PipelineRun | spec.TaskRunSpecs.ExecutionMode | Whether or not this specific TaskRun should be run hermetically during a PipelineRun. This overrides the Task, Pipeline and PipelineRun defaults. |
This execution mode will be applied to all **user-specified** containers, including Steps and Sidecars. Tekton-injected ones (init containers, resource containers) will not run with this policy.
diff --git a/teps/0026-interceptor-plugins.md b/teps/0026-interceptor-plugins.md
index f8ac02674..db3b2580f 100644
--- a/teps/0026-interceptor-plugins.md
+++ b/teps/0026-interceptor-plugins.md
@@ -406,7 +406,7 @@ data:
* Extensibility: Having a CRD allows us to add new features to Interceptors down the line. For instance, we might want to support a `tlsClientConfig` field that allows the listener to communicate with the interceptor over TLS (similar to admission webhook's [client config](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#webhookclientconfig-v1-admissionregistration-k8s-io)). It also leaves open the possibility in the future of support alternate transports (e.g. GRPC instead of HTTP).
-### Use go-plugin for built-in interceptors
+### Use go-plugin for built-in interceptors
We'd leverage a library like HashiCorp's go-plugin for built-in interceptors while keeping the existing webhhok interface for extensibility. In this model, the interceptor will run as separate processes but within the same pod. They will communicate with the listener over RPC. So, in many ways this is similar to the proposal but the key difference is that everything runs in the same pod. This is a reasonable alternative. But it does lead us to having to maintain two different interceptor models - one for plugin one for webhooks. The main implications are:
* We can keep using the same service account model as before.
@@ -420,7 +420,7 @@ We'd leverage a library like HashiCorp's go-plugin for built-in interceptors whi
We'll package in built-in interceptors as we do now, but an operator can turn some of the interceptors "off" using a flag or a config map. This is similar to Kubernetes where some admission controllers are [compiled in](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) and can only be [enabled ](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-controller)or disabled. Uses can extend by writing and registering their own [dynamic admission webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) (similar to webhook interceptors).
-### Implement built-in interceptors using the current webhook interface
+### Implement built-in interceptors using the current webhook interface
In this model, the built-in interceptors will still be implemented as separate services but they will use the existing Webhook Interface.
* Passing interceptors params (e.g. the CEL filter expression) would be much more verbose. We'd have to invent extra headers to pass this information through. As an example, this is what an CEL interceptor usage would look like:
diff --git a/teps/0027-https-connection-to-triggers-eventlistener.md b/teps/0027-https-connection-to-triggers-eventlistener.md
index ed238b2ce..1b5ed6149 100644
--- a/teps/0027-https-connection-to-triggers-eventlistener.md
+++ b/teps/0027-https-connection-to-triggers-eventlistener.md
@@ -150,6 +150,6 @@ At high level below are few implementation details
* Using thirdparty solutions like service mesh.
* Writing simple sidecar which inject tls certs into the eventlistener pod.
-## References
+## References
1. GitHub issue: https://github.com/tektoncd/triggers/issues/650
2. Implementation: https://github.com/tektoncd/triggers/pull/819
diff --git a/teps/0028-task-execution-status-at-runtime.md b/teps/0028-task-execution-status-at-runtime.md
index 02333d3fb..ad3b53a48 100644
--- a/teps/0028-task-execution-status-at-runtime.md
+++ b/teps/0028-task-execution-status-at-runtime.md
@@ -80,11 +80,11 @@ This variable is instantiated and available at the runtime. In the following exa
fi
```
-| State | Description |
-| ----- | ----------- |
-| `Succeeded` | The `pipelineTask` was successful i.e. a respective pod was created and completed successfully. The `pipelineTask` had a `taskRun` with `Succeeded` `ConditionType` and `True` `ConditionStatus`. |
-| `Failed` | The `pipelineTask` failed i.e. a respective pod was created but exited with error. The `pipelineTask` has a `taskRun` with `Succeeded` `ConditionType`, `False` `ConditionStatus` and have exhausted all the retries. |
-| `None` | no execution state available either (1) the `pipeline` stopped executing `dag` tasks before it could get to this task i.e. this task was not started/executed or (2) the `pipelineTask` is `skipped` because of `when expression` or one of the parent tasks was `skipped`. It is part of `pipelineRun.Status.SkippedTasks`. |
+| State | Description |
+|-------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `Succeeded` | The `pipelineTask` was successful i.e. a respective pod was created and completed successfully. The `pipelineTask` had a `taskRun` with `Succeeded` `ConditionType` and `True` `ConditionStatus`. |
+| `Failed` | The `pipelineTask` failed i.e. a respective pod was created but exited with error. The `pipelineTask` has a `taskRun` with `Succeeded` `ConditionType`, `False` `ConditionStatus` and have exhausted all the retries. |
+| `None` | no execution state available either (1) the `pipeline` stopped executing `dag` tasks before it could get to this task i.e. this task was not started/executed or (2) the `pipelineTask` is `skipped` because of `when expression` or one of the parent tasks was `skipped`. It is part of `pipelineRun.Status.SkippedTasks`. |
### User Stories
diff --git a/teps/0029-step-workspaces.md b/teps/0029-step-workspaces.md
index 29e426525..767e65249 100644
--- a/teps/0029-step-workspaces.md
+++ b/teps/0029-step-workspaces.md
@@ -15,9 +15,9 @@ status: implemented
- [Goals](#goals)
- [Requirements](#requirements)
- [Proposal](#proposal)
- - [Add workspaces to Steps](#add--to-)
- - [Add workspaces to Sidecars](#add--to--1)
- - [Allow workspaces in Steps and Sidecars to have their own mountPath](#allow--in--and--to-have-their-own-)
+ - [Add workspaces to Steps](#add-workspaces-to-steps)
+ - [Add workspaces to Sidecars](#add-workspaces-to-sidecars)
+ - [Allow workspaces in Steps and Sidecars to have their own mountPath](#allow-workspaces-in-steps-and-sidecars-to-have-their-own-mountpath)
- [User Stories](#user-stories)
- [Story 1](#story-1)
- [Story 2](#story-2)
diff --git a/teps/0033-tekton-feature-gates.md b/teps/0033-tekton-feature-gates.md
index 64a58f544..f4f1b1b33 100644
--- a/teps/0033-tekton-feature-gates.md
+++ b/teps/0033-tekton-feature-gates.md
@@ -233,20 +233,20 @@ This allows administrators to opt into allowing their users to use alpha and bet
Since we do not yet have any `v1` CRDs, the behavior will look like:
-| Feature Versions -> | beta | alpha |
-| --- | --- | --- |
-| stable | x | |
-| alpha | x | x |
+| Feature Versions -> | beta | alpha |
+|---------------------|------|-------|
+| stable | x | |
+| alpha | x | x |
x == "**enabled**"
Once we have `v1` CRDs it will become:
| Feature Versions -> | v1 | beta | alpha |
-| --- | --- | --- | --- |
-| stable | x | | |
-| beta | x | x | |
-| alpha | x | x | x |
+|---------------------|----|------|-------|
+| stable | x | | |
+| beta | x | x | |
+| alpha | x | x | x |
For example:
diff --git a/teps/0040-ignore-step-errors.md b/teps/0040-ignore-step-errors.md
index 460a99cd6..acd7624c3 100644
--- a/teps/0040-ignore-step-errors.md
+++ b/teps/0040-ignore-step-errors.md
@@ -24,7 +24,7 @@ authors:
- [Advantages](#advantages)
- [Single Source of Truth](#single-source-of-truth)
- [Alternatives](#alternatives)
- - [A bool flag](#a--flag)
+ - [A bool flag](#a-bool-flag)
- [exitCode set to 0 through 255](#exitcode-set-to-0-through-255)
- [Future Work](#future-work)
- [Step exit code as a task result](#step-exit-code-as-a-task-result)
diff --git a/teps/0042-taskrun-breakpoint-on-failure.md b/teps/0042-taskrun-breakpoint-on-failure.md
index c0ef8261c..d52e18e16 100644
--- a/teps/0042-taskrun-breakpoint-on-failure.md
+++ b/teps/0042-taskrun-breakpoint-on-failure.md
@@ -113,7 +113,7 @@ To exit a step which has been paused upon failure, the step would wait on a file
would unpause and exit the step container. eg: Step 0 fails and is paused. Writing `0.breakpointexit` in `/tekton/tools`
would unpause and exit the step container.
-### Debug Environment Additions
+### Debug Environment Additions
#### Mounts
diff --git a/teps/0044-data-locality-and-pod-overhead-in-pipelines.md b/teps/0044-data-locality-and-pod-overhead-in-pipelines.md
index be961a77f..8c182d86c 100644
--- a/teps/0044-data-locality-and-pod-overhead-in-pipelines.md
+++ b/teps/0044-data-locality-and-pod-overhead-in-pipelines.md
@@ -223,7 +223,7 @@ Some functionality required to run multiple Tasks in a pod could be supported wi
some functionality would require changes to this code, and some functionality may not be possible at all.
* Functionality that could be supported with current pod logic (e.g. by
- [translating a Pipeline directly to a TaskRun](#pipeline-executed-as-taskrun)):
+ [translating a Pipeline directly to a TaskRun](#pipeline-executed-as-a-taskrun)):
* Sequential tasks (specified using [`runAfter`](https://github.com/tektoncd/pipeline/blob/main/docs/pipelines.md#using-the-runafter-parameter))
* [Parallel tasks](https://github.com/tektoncd/pipeline/blob/main/docs/pipelines.md#configuring-the-task-execution-order)
* [String params](https://github.com/tektoncd/pipeline/blob/main/docs/pipelines.md#specifying-parameters)
@@ -259,7 +259,7 @@ some functionality would require changes to this code, and some functionality ma
* [Custom tasks](https://github.com/tektoncd/pipeline/blob/main/docs/pipelines.md#using-custom-tasks) - the pod would
need to be able to create and watch Custom Tasks, or somehow lean on the Pipelines controller to do this
* Functionality that might not be possible (i.e. constrained by pods themselves):
- * Any dynamically created TaskRuns. This is discussed in more detail [below](#dynamically-created-tasks-in-pipelines).
+ * Any dynamically created TaskRuns. This is discussed in more detail [below](#dynamically-created-taskruns-in-pipelines).
* Running each Task with a different `ServiceAccount` - the pod has one ServiceAccount as a whole
(See also [functionality supported by experimental Pipeline to TaskRun](https://github.com/tektoncd/experimental/tree/main/pipeline-to-taskrun#supported-pipeline-features))
@@ -800,7 +800,7 @@ but lends itself less well to adding authoring time configuration later.
### Controller option to execute Pipelines in a pod
In this option, the Tekton controller can be configured to always execute Pipelines inside one pod.
-This would require similar functionality to the [pipeline in a pod](#pipeline-in-a-pod-plus-pipelines-in-pipelines),
+This would require similar functionality to the [pipeline in a pod](#pipeline-functionality-supported-in-pods),
but provide less flexibility to Task and Pipeline authors, as only cluster administrators will be able to control scheduling.
### TaskRun controller allows Tasks to contain other Tasks
@@ -915,7 +915,7 @@ TaskRuns in the same pod. The controller would be responsible for reconciling bo
created from the TaskGroup.
The controller would need to determine how many TaskRuns are needed when the TaskGroup is first reconciled, due to
-[limitations associated with dynamically creating Tasks](#dynamically-created-tasks-in-pipelines).
+[limitations associated with dynamically creating Tasks](#dynamically-created-taskruns-in-pipelines).
When the TaskGroup is first reconciled, it would create all TaskRuns needed, with those that are not ready to execute marked as "pending",
and a pod with one container per TaskRun. The TaskGroup would store references to any TaskRuns created, and Task statuses would be stored on the TaskRuns.
diff --git a/teps/0046-finallytask-execution-post-timeout.md b/teps/0046-finallytask-execution-post-timeout.md
index 20146806f..3be0d6694 100644
--- a/teps/0046-finallytask-execution-post-timeout.md
+++ b/teps/0046-finallytask-execution-post-timeout.md
@@ -107,11 +107,10 @@ spec:
The finally task runs after the task completion and both execute normally.
-| NAME | TASK NAME | STARTED | DURATION | STATUS |
-|----------------------------------------------------------------|------------------|----------------|------------|------------------------|
-| ∙ hello-world-pipeline-run-with-timeout-task2-kxtc6 | task2 | 19 seconds ago | 7 seconds | Succeeded |
-| ∙ hello-world-pipeline-run-with-timeout-task1-bqmzz | task1 | 35 seconds ago | 16 seconds | Succeeded |
-| | | | | |
+| NAME | TASK NAME | STARTED | DURATION | STATUS |
+|-----------------------------------------------------|-----------|----------------|------------|-----------|
+| ∙ hello-world-pipeline-run-with-timeout-task2-kxtc6 | task2 | 19 seconds ago | 7 seconds | Succeeded |
+| ∙ hello-world-pipeline-run-with-timeout-task1-bqmzz | task1 | 35 seconds ago | 16 seconds | Succeeded |
Now if we change the task script in order to have it exceed its timeout (30s), we get the following status report:
@@ -120,7 +119,6 @@ Now if we change the task script in order to have it exceed its timeout (30s), w
|-----------------------------------------------------|-----------|----------------|------------|------------------------|
| ∙ hello-world-pipeline-run-with-timeout-task2-44tsb | task2 | 8 seconds ago | 5 seconds | Succeeded |
| ∙ hello-world-pipeline-run-with-timeout-task1-wgcq7 | task1 | 38 seconds ago | 30 seconds | Failed(TaskRunTimeout) |
-| | | | | |
The finally task still executes after the task failure.
@@ -133,8 +131,6 @@ Finally if we reduce the pipelinerun timeout to 10s, our status report shows:
| NAME | TASK NAME | STARTED | DURATION | STATUS |
|-----------------------------------------------------|-----------|---------------|------------|------------------------|
| ∙ hello-world-pipeline-run-with-timeout-task1-q7fw4 | task1 | 2 minutes ago | 30 seconds | Failed(TaskRunTimeout) |
-| | | | | |
-| | | | | |
The pipelinerun timeout take precedence over the task timeout. After 10s the task fails... And the finally task does not get the chance to execute.
diff --git a/teps/0048-task-results-without-results.md b/teps/0048-task-results-without-results.md
index 2d076e6e5..72b805fa5 100644
--- a/teps/0048-task-results-without-results.md
+++ b/teps/0048-task-results-without-results.md
@@ -19,12 +19,12 @@ status: implementable
- [Requirements](#requirements)
- [Use Cases](#use-cases)
- [Consuming task results from the conditional tasks](#consuming-task-results-from-the-conditional-tasks)
- - [Pipeline Results from the conditional tasks](#-from-the-conditional-tasks)
- - [Task claiming to produce Results fails if it doesn't produces](#task-claiming-to-produce--fails-if-it-doesnt-produces)
+ - [Pipeline Results from the conditional tasks](#pipeline-results-from-the-conditional-tasks)
+ - [Task claiming to produce Results fails if it doesn't produces](#task-claiming-to-produce-results-fails-if-it-doesnt-produces)
- [Proposal](#proposal)
- - [Consuming Task Result from the conditional tasks](#consuming---from-the-conditional-tasks)
- - [Pipeline Results from the conditional tasks](#-from-the-conditional-tasks-1)
- - [Task claiming to produce Result fails if it doesn't produces](#-claiming-to-produce--fails-if-it-doesnt-produces)
+ - [Consuming Task Result from the conditional tasks](#consuming-task-results-from-the-conditional-tasks)
+ - [Pipeline Results from the conditional tasks](#pipeline-results-from-the-conditional-tasks-1)
+ - [Task claiming to produce Result fails if it doesn't produces](#task-claiming-to-produce-result-fails-if-it-doesnt-produces)
- [Test Plan](#test-plan)
- [Alternatives](#alternatives)
- [Declaring Results as Optional](#declaring-results-as-optional)
@@ -708,7 +708,7 @@ produce `Results` as discussed in [tektoncd/pipeline#3497](https://github.com/te
It does not address the use cases for providing default `Results` that can be consumed in subsequent `Tasks`.
-## Future Work
+## Future Work
Determine if we need default `Results` declared at runtime in the future, and how we can support that.
diff --git a/teps/0049-aggregate-status-of-dag-tasks.md b/teps/0049-aggregate-status-of-dag-tasks.md
index cbf8cf084..a142e603c 100644
--- a/teps/0049-aggregate-status-of-dag-tasks.md
+++ b/teps/0049-aggregate-status-of-dag-tasks.md
@@ -104,12 +104,12 @@ finally:
values: ["Failed"]
```
-| State | Description |
-| ----- | ----------- |
-| `Succeeded` | All `dag` tasks have succeeded. |
-| `Failed` | Any one of the `dag` task failed. |
-| `Completed` | All `dag` tasks completed successfully including one or more skipped tasks. |
-| `None` | No aggregate execution status available (i.e. none of the above) because some of the tasks are still pending or running or cancelled or timed out. |
+| State | Description |
+|-------------|----------------------------------------------------------------------------------------------------------------------------------------------------|
+| `Succeeded` | All `dag` tasks have succeeded. |
+| `Failed` | Any one of the `dag` task failed. |
+| `Completed` | All `dag` tasks completed successfully including one or more skipped tasks. |
+| `None` | No aggregate execution status available (i.e. none of the above) because some of the tasks are still pending or running or cancelled or timed out. |
`$(tasks.status)` is not accessible in any `dag` task but only accessible in a `finally` task. The `pipeline` creation
will fail with the validation error if `$(tasks.status)` is used in any `dag` task.
diff --git a/teps/0053-nested-triggers.md b/teps/0053-nested-triggers.md
index 49ea93ccf..a676a1bf9 100644
--- a/teps/0053-nested-triggers.md
+++ b/teps/0053-nested-triggers.md
@@ -30,7 +30,7 @@ authors:
- [Advantages](#advantages-2)
- [Disadvantages](#disadvantages-2)
- [Implementation Decision](#implementation-decision)
- - [Example triggerGroup Configuration](#example--configuration)
+ - [Example triggerGroup Configuration](#example-triggerGroup-configuration)
- [Implementation PRs](#implementation-prs)
- [References](#references)
diff --git a/teps/0056-pipelines-in-pipelines.md b/teps/0056-pipelines-in-pipelines.md
index e1b3189e0..9accf7f33 100644
--- a/teps/0056-pipelines-in-pipelines.md
+++ b/teps/0056-pipelines-in-pipelines.md
@@ -46,10 +46,10 @@ see-also:
- [Future Work](#future-work)
- [Runtime Specification](#runtime-specification)
- [Alternatives](#alternatives)
- - [Specification - Group PipelineRef and PipelineSpec](#specification---group--and-)
- - [Specification - Use PipelineRunSpec in PipelineTask](#specification---use--in-)
- - [Specification - Reorganize PipelineTask](#specification---reorganize-)
- - [Runtime specification - provide overrides for PipelineRun](#runtime-specification---provide-overrides-for-)
+ - [Specification - Group PipelineRef and PipelineSpec](#specification---group-pipelineref-and-pipelinespec)
+ - [Specification - Use PipelineRunSpec in PipelineTask](#specification---use-pipelinerunspec-in-pipelinetask)
+ - [Specification - Reorganize PipelineTask](#specification---reorganize-pipelinetask)
+ - [Runtime specification - provide overrides for PipelineRun](#runtime-specification---provide-overrides-for-pipelinerun)
- [Runtime specification - provide overrides for all runtime types](#runtime-specification---provide-overrides-for-all-runtime-types)
- [Status - Require Minimal Status](#status---require-minimal-status)
- [Status - Populate Embedded and Minimal Status](#status---populate-embedded-and-minimal-status)
@@ -543,7 +543,7 @@ spec:
### Results
-#### Consuming Results
+#### Consuming Results
`Pipelines` in `Pipelines` will consume `Results`, in the same way as `Tasks` in `Pipelines`.
@@ -632,7 +632,7 @@ spec:
name: notification
```
-### Workspaces
+### Workspaces
`PipelineTasks` with `Pipelines` can reference `Workspaces`, in the same way as `PipelineTasks` with `Tasks`. In these
case, the `Workspaces` from the parent `PipelineRun` will be bound to the child `PipelineRun`.
@@ -716,7 +716,7 @@ map to `timeouts.pipeline` in the child `PipelineRun`.
If users need finer-grained timeouts for child `PipelineRuns` as those supported in parent `PipelineRuns`, we can
explore supporting them in future work - see [possible solution](#runtime-specification---provide-overrides-for-pipelinerun).
-### Matrix
+### Matrix
Users can fan out `PipelineTasks` with `Tasks` and `Custom Tasks` into multiple `TaskRuns` and `Runs` using `Matrix`.
In the same way, users can fan out `PipelineTasks` with `Pipelines` into multiple child `PipelineRuns`. This provides
diff --git a/teps/0058-graceful-pipeline-run-termination.md b/teps/0058-graceful-pipeline-run-termination.md
index 2bc8fa87e..5bb1a5186 100644
--- a/teps/0058-graceful-pipeline-run-termination.md
+++ b/teps/0058-graceful-pipeline-run-termination.md
@@ -146,10 +146,10 @@ No impact on performance.
In this proposal the list of statuses users can set in `spec.status` is extended to:
- | don't run finally tasks | run finally tasks
------- | ------------------------ | -----------------------------
-cancel | Cancelled | CancelledRunFinally
-stop | | StoppedRunFinally
+| | don't run finally tasks | run finally tasks |
+|--------|-------------------------|---------------------|
+| cancel | Cancelled | CancelledRunFinally |
+| stop | | StoppedRunFinally |
The existing state "PipelineRunCancelled" is deprecated and replaced by "Cancelled".
diff --git a/teps/0060-remote-resource-resolution.md b/teps/0060-remote-resource-resolution.md
index 7ffcf3e93..c47d1a487 100644
--- a/teps/0060-remote-resource-resolution.md
+++ b/teps/0060-remote-resource-resolution.md
@@ -19,19 +19,19 @@ authors:
- [Use Cases (optional)](#use-cases-optional)
- [Requirements](#requirements)
- [Proposal](#proposal)
- - [1. Establish a new syntax in Tekton Pipelines' taskRef and pipelineRef structs for remote resources](#1-establish-a-new-syntax-in-tekton-pipelines--and--structs-for-remote-resources)
- - [2. Implement procedure for resolution: ResolutionRequest CRD](#2-implement-procedure-for-resolution--crd)
+ - [1. Establish a new syntax in Tekton Pipelines' taskRef and pipelineRef structs for remote resources](#1-establish-a-new-syntax-in-tekton-pipelines-taskref-and-pipelineref-structs-for-remote-resources)
+ - [2. Implement procedure for resolution: ResolutionRequest CRD](#2-implement-procedure-for-resolution-resolutionrequest-crd)
- [3. Create a new Tekton Resolution project](#3-create-a-new-tekton-resolution-project)
- [Risks and Mitigations](#risks-and-mitigations)
- [Relying on a CRD as storage for in-lined resolved data](#relying-on-a-crd-as-storage-for-in-lined-resolved-data)
- [Changing the way it works means potentially rewriting multiple resolvers](#changing-the-way-it-works-means-potentially-rewriting-multiple-resolvers)
- [Data Integrity](#data-integrity)
- [User Experience (optional)](#user-experience-optional)
- - [Simple flow: user submits TaskRun using public catalog Task](#simple-flow-user-submits--using-public-catalog-)
+ - [Simple flow: user submits TaskRun using public catalog Task](#simple-flow-user-submits-taskrun-using-public-catalog-task)
- [Performance](#performance)
- [Design Details](#design-details)
- [New Pipelines syntax schema](#new-pipelines-syntax-schema)
- - [ResolutionRequest objects](#-objects)
+ - [ResolutionRequest objects](#resolutionrequest-objects)
- [YAML Examples](#yaml-examples)
- [Resolver specifics](#resolver-specifics)
- [In-Cluster Resolver](#in-cluster-resolver)
@@ -63,7 +63,7 @@ authors:
- [Applicability For Other Tekton Projects](#applicability-for-other-tekton-projects-4)
- [A CRD That Wraps Tekton's Existing Types](#a-crd-that-wraps-tektons-existing-types)
- [Applicability For Other Tekton Projects](#applicability-for-other-tekton-projects-5)
- - [Use a pending Status on PipelineRuns/TaskRuns With Embedded Resolution Info](#use-a--status-on-pipelinerunstaskruns-with-embedded-resolution-info)
+ - [Use a pending Status on PipelineRuns/TaskRuns With Embedded Resolution Info](#use-a-pending-status-on-pipelinerunstaskruns-with-embedded-resolution-info)
- [Applicability For Other Tekton Projects](#applicability-for-other-tekton-projects-6)
- [Use an Admission Controller to Perform Resolution](#use-an-admission-controller-to-perform-resolution)
- [Applicability For Other Tekton Projects](#applicability-for-other-tekton-projects-7)
diff --git a/teps/0072-results-json-serialized-records.md b/teps/0072-results-json-serialized-records.md
index 63c21395e..04ddd4ee3 100644
--- a/teps/0072-results-json-serialized-records.md
+++ b/teps/0072-results-json-serialized-records.md
@@ -321,14 +321,14 @@ features in CEL will no longer work out of the box -
now an opaque byte string) - users will need to reference the `type` field:
| Before | After |
- | ---------------------------------------------------- | ----------------------------------------------------- |
+ |------------------------------------------------------|-------------------------------------------------------|
| type(record.data) == tekton.pipeline.v1beta1.TaskRun | record.data.type == "tekton.pipeline.v1beta1.TaskRun" |
- Underlying data cannot be directly referenced - users will need to use the
`value` field:
| Before | After |
- | -------------------------------- | -------------------------------------- |
+ |----------------------------------|----------------------------------------|
| record.data.name.contains("foo") | record.data.value.name.contains("foo") |
It is possible that we might be able to replicate some of the well-known Any
diff --git a/teps/0074-deprecate-pipelineresources.md b/teps/0074-deprecate-pipelineresources.md
index ac9385e29..f68bad242 100644
--- a/teps/0074-deprecate-pipelineresources.md
+++ b/teps/0074-deprecate-pipelineresources.md
@@ -19,7 +19,7 @@ authors:
- [Requirements](#requirements)
- [Proposal](#proposal)
- [Features that will replace PipelineResources functionality](#features-that-will-replace-pipelineresources-functionality)
- - [New repo: tektoncd/images](#new-repo-tektoncdimages)
+ - [Images used in PipelineResources](#images-used-in-pipelineresources)
- [Risks and Mitigations](#risks-and-mitigations)
- [User Experience](#user-experience)
- [Design Details](#design-details)
@@ -46,14 +46,14 @@ This TEP proposes deprecating the CRD [PipelineResource](https://github.com/tekt
in its current form, and addressing each problem PipelineResources were solving with specific features (see
[Design details](#design-details) for more depth on how the listed replacements address the feature):
-| PipelineResources Feature| Replacement |
-|---|---|
-| Augmenting Tasks with steps that execute on the same pod | [TEP-0044 Decoupling Task composition from scheduling](https://github.com/tektoncd/community/blob/main/teps/0044-decouple-task-composition-from-scheduling.md) |
-| Automatic storage provisioning | [volumeClaimTemplates](https://github.com/tektoncd/pipeline/blob/main/docs/workspaces.md#volumeclaimtemplate), [TEP-0044 Decoupling Task composition from scheduling](https://github.com/tektoncd/community/blob/main/teps/0044-decouple-task-composition-from-scheduling.md) + catalog tasks |
-| PipelineResource specific credential handling | [TEP-0044 Decoupling Task composition from scheduling](https://github.com/tektoncd/community/blob/main/teps/0044-decouple-task-composition-from-scheduling.md) |
-| Expressing typed inputs and outputs | [TEP-0075 Dictionary/object params and results](https://github.com/tektoncd/community/pull/479) |
-| Reusable parameter bundles | [TEP-0075 Dictionary/object params and results](https://github.com/tektoncd/community/pull/479) |
-| Contract around files provided or expected on disk | [TEP-0030 Workspace paths](https://github.com/tektoncd/community/blob/main/teps/0030-workspace-paths.md) |
+| PipelineResources Feature | Replacement |
+|----------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Augmenting Tasks with steps that execute on the same pod | [TEP-0044 Decoupling Task composition from scheduling](https://github.com/tektoncd/community/blob/main/teps/0044-decouple-task-composition-from-scheduling.md) |
+| Automatic storage provisioning | [volumeClaimTemplates](https://github.com/tektoncd/pipeline/blob/main/docs/workspaces.md#volumeclaimtemplate), [TEP-0044 Decoupling Task composition from scheduling](https://github.com/tektoncd/community/blob/main/teps/0044-decouple-task-composition-from-scheduling.md) + catalog tasks |
+| PipelineResource specific credential handling | [TEP-0044 Decoupling Task composition from scheduling](https://github.com/tektoncd/community/blob/main/teps/0044-decouple-task-composition-from-scheduling.md) |
+| Expressing typed inputs and outputs | [TEP-0075 Dictionary/object params and results](https://github.com/tektoncd/community/pull/479) |
+| Reusable parameter bundles | [TEP-0075 Dictionary/object params and results](https://github.com/tektoncd/community/pull/479) |
+| Contract around files provided or expected on disk | [TEP-0030 Workspace paths](https://github.com/tektoncd/community/blob/main/teps/0030-workspace-paths.md) |
This still leaves the door open for adding a similar abstraction, but in the meantime, we can remove this contentious
concept from our API and move forward toward our [v1 Pipelines release](https://github.com/tektoncd/pipeline/issues/3548).
@@ -299,7 +299,7 @@ without requiring PipelineResources:
proxy information, etc., which is why
[the git-clone task has 15 parameters](https://github.com/tektoncd/catalog/blob/main/task/git-clone/0.4/README.md#parameters),
but having to duplicate these params each time you use them has led to the
- [git-rebase lacking many of these params]([the git-rebase task has 10 parameters](https://github.com/tektoncd/catalog/blob/main/task/git-rebase/0.1/README.md#parameters))
+ [git-rebase lacking many of these params](https://github.com/tektoncd/catalog/blob/main/task/git-rebase/0.1/README.md#parameters)
* *Replacement*: Supporting objects ([TEP-0075](https://github.com/tektoncd/community/pull/479)) and eventually more
complex params and results will allow us to use those to define known interfaces, e.g. a dictionary of values you
need when connecting to git. This will still be duplicated each time, but we might still be able to use this feature
diff --git a/teps/0075-object-param-and-result-types.md b/teps/0075-object-param-and-result-types.md
index f44fb8df2..7775f52b5 100644
--- a/teps/0075-object-param-and-result-types.md
+++ b/teps/0075-object-param-and-result-types.md
@@ -43,7 +43,7 @@ authors:
- [Design Evaluation](#design-evaluation)
- [Drawbacks](#drawbacks)
- [Alternatives](#alternatives)
-- [Alternative #1: Introduce a schema section specifically for the type schema](#alternative-1--introduce-a--section-specifically-for-the-type-schema)
+- [Alternative #1: Introduce a schema section specifically for the type schema](#alternative-1-introduce-a-schema-section-specifically-for-the-type-schema)
- [Alternative #2: Create a wrapper for JSON Schema](#alternative-2-create-a-wrapper-for-json-schema)
- [Alternative #3: Create our own syntax just for dictionaries](#alternative-3-create-our-own-syntax-just-for-dictionaries)
- [More alternatives](#more-alternatives)
@@ -289,7 +289,7 @@ objects will likely use string values
This proposal suggests adding a new `properties` section to param and result definition. If we later support more json
schema attribute such as `additionalProperties` and `required`, we'd also support them at the same level as the
`properties` field here. (
-See [Alternative #1 adding a schema section](#alternative-1--introduce-a-schema-section-specifically-for-the-type-schema)
+See [Alternative #1 adding a schema section](#alternative-1-introduce-a-schema-section-specifically-for-the-type-schema)
.)
(At that point we should also consider whether we want to adopt strict JSON schema syntax or if we want to support Open
API schema instead; see [why JSON Schema](#why-json-schema).)
diff --git a/teps/0076-array-result-types.md b/teps/0076-array-result-types.md
index da0a2d9b1..681d3d682 100644
--- a/teps/0076-array-result-types.md
+++ b/teps/0076-array-result-types.md
@@ -172,7 +172,7 @@ This TEP proposes expanding support for arrays in Tasks and Pipelines by adding:
1. **Use case for array indexing: Tasks that wrap CLIs**
Array indexing would make it possible for Tasks that wrap generic CLIs to provide
- (short - see [size limits](#size-limit)) stdout output as array results which could be indexed by consuming tasks.
+ (short - see [size limits](#size-limits)) stdout output as array results which could be indexed by consuming tasks.
For example [the gcloud CLI task](https://github.com/tektoncd/catalog/tree/main/task/gcloud/0.1): the CLI could be
doing all kinds of different things depending on the arguments (e.g. `gcloud projects list` vs
`gcloud container clusters list`). In order to consume the output in downstream tasks (with minimal effort), you
diff --git a/teps/0079-tekton-catalog-support-tiers.md b/teps/0079-tekton-catalog-support-tiers.md
index dff52c923..cef2bdeb1 100644
--- a/teps/0079-tekton-catalog-support-tiers.md
+++ b/teps/0079-tekton-catalog-support-tiers.md
@@ -533,7 +533,7 @@ of the Catalog, such as by using the `catalog-support-tier` field in Hub configu
There's no clear benefit for allowing Contributors to host Catalogs in the tektoncd-catalog GitHub Org. However,
it adds more maintenance burden because the Tekton Maintainers would have to create the repositories, and provide
general oversight. Contributors are already hosting Catalogs in their own organizations and repositories e.g.
-[eBay][ebay] and [Buildpacks][buildpacks].
+[eBay][eBay] and [Buildpacks][buildpacks].
### Automated Testing and Dogfooding
@@ -1071,7 +1071,7 @@ We only automate the signature verification process in the CI in the current des
* [Tekton Catalog and Hub Design][catalog-hub-design]
* [Pipeline Catalog Integration Proposal][catalog-proposal]
* [Original Tekton Catalog Tiers Proposal][catalog-support-tiers]
-* [Tekton Catalog Test Infrastructure Design Doc](doc-infra)
+* [Tekton Catalog Test Infrastructure Design Doc][doc-infra]
* [TEP for Catalog Test Requirements and Infra for Verified+][tep-infra]
* [TEP-0003: Tekton Catalog Organization][tep-0003]
* [TEP-0091: Verified Remote Resources][tep-0091]
diff --git a/teps/0081-add-chains-subcommand-to-the-cli.md b/teps/0081-add-chains-subcommand-to-the-cli.md
index 7b7b41c52..ebcfa46f4 100644
--- a/teps/0081-add-chains-subcommand-to-the-cli.md
+++ b/teps/0081-add-chains-subcommand-to-the-cli.md
@@ -143,7 +143,7 @@ instead of:
## Requirements
There may not be any specific requirements, depending on the commands being
-implemented. See the [Notes/Caveats (optional)](notes-caveats-optional) for more
+implemented. See the [Notes/Caveats (optional)](#notescaveats-optional) for more
details.
## Proposal
@@ -216,7 +216,7 @@ Why should this TEP _not_ be implemented?
The alternative is to use a combination of shell tools and to know which exact
annotation or key to query/update. It was ruled out since it complicates the
operations for no good reason. See the
-[Use Cases (optional)](use-cases-optional) section for some examples.
+[Use Cases (optional)](#other-use-case-ideas) section for some examples.
One other alternative would be that chains provides a `tkn-chains` binary, and
with the "execution model" we have in `tkn`, it would appear as a subcommand.One
diff --git a/teps/0082-workspace-hinting.md b/teps/0082-workspace-hinting.md
index 2de35e950..05d68ab89 100644
--- a/teps/0082-workspace-hinting.md
+++ b/teps/0082-workspace-hinting.md
@@ -36,7 +36,7 @@ authors:
- [Cons](#cons-2)
- [Loosely-Coupled Metadata](#loosely-coupled-metadata)
- [Pros](#pros-2)
- - [Syntactic Alternatives to workspaces](#syntactic-alternatives-to-)
+ - [Syntactic Alternatives to workspaces](#syntactic-alternatives-to-workspaces)
- [Pros](#pros-3)
- [Cons](#cons-3)
- [Infrastructure Needed (optional)](#infrastructure-needed-optional)
diff --git a/teps/0084-endtoend-provenance-collection.md b/teps/0084-endtoend-provenance-collection.md
index df299e8f6..d08383166 100644
--- a/teps/0084-endtoend-provenance-collection.md
+++ b/teps/0084-endtoend-provenance-collection.md
@@ -560,11 +560,11 @@ information.
New configuration options will be introduced to control the behavior for producing and storing
pipelinerun attestations. These should behave as similar as possible to their taskrun counterparts.
-| Key | Description | Supported Values | Default |
-| --- | ----------- | ---------------- | ------- |
-| `artifacts.pipelinerun.format` | The format to store TaskRun payloads in. | tekton, in-toto | tekton |
-| `artifacts.pipelinerun.storage` | The storage backend to store PipelineRun signatures and attestations in. Multiple backends can be specified with comma-separated list (“tekton,oci”). To disable the PipelineRun artifact input an empty string (""). | tekton, oci, gcs, docdb, grafeas | tekton |
-| `artifacts.pipelinerun.signer` | The signature backend to sign Taskrun payloads with. | x509, kms | x509 |
+| Key | Description | Supported Values | Default |
+|---------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------|---------|
+| `artifacts.pipelinerun.format` | The format to store TaskRun payloads in. | tekton, in-toto | tekton |
+| `artifacts.pipelinerun.storage` | The storage backend to store PipelineRun signatures and attestations in. Multiple backends can be specified with comma-separated list (“tekton,oci”). To disable the PipelineRun artifact input an empty string (""). | tekton, oci, gcs, docdb, grafeas | tekton |
+| `artifacts.pipelinerun.signer` | The signature backend to sign Taskrun payloads with. | x509, kms | x509 |
It is expected that storage has an ever changing set of supported values, just like it is for
taksruns. There should be parity between the storages supported by both taskrun and pipelinerun
diff --git a/teps/0086-changing-the-way-result-parameters-are-stored.md b/teps/0086-changing-the-way-result-parameters-are-stored.md
index 71590a58a..6918c13a2 100644
--- a/teps/0086-changing-the-way-result-parameters-are-stored.md
+++ b/teps/0086-changing-the-way-result-parameters-are-stored.md
@@ -235,7 +235,7 @@ Implementations should take care to ensure the integrity of result/param content
- ideally, with tight access controls to prevent tampering and leakage
for example, an implementation that stored contents in GCS could use signed URLs to only authorize one POST of object contents, only authorize GETs for only one hour, and delete the object contents entirely after one day.
-However, we are currently leaning toward using implementations of [the HTTP service](#dedicated-http-service) as the place
+However, we are currently leaning toward using implementations of [the HTTP service](#dedicated-storage-api-service) as the place
to plug in support for different backends instead.
This alternative provides options for handling a change to result parameter storage and potentially involves adjusting the
@@ -279,7 +279,7 @@ We need to consider both performance and security impacts of the changes and tra
#### Design Details
-This approach for recording results coupled with the [*Dedicated HTTP Service*](#dedicated-http-service)
+This approach for recording results coupled with the [*Dedicated HTTP Service*](#dedicated-storage-api-service)
(with a well defined interface that can be swapped out) can help abstract the backend. With this approach the default
backend could be a ConfigMap (or CRD) - or we could even continue to use the TaskRun itself to store results - since
only the HTTP service would need the permissions required to make teh edits (vs a solution where we need to on the fly
@@ -395,7 +395,7 @@ Questions:
- Should the sidecar be responsible for deciding whether the result should be reported by-value or by-reference? Or is that a controller-wide configuration?
- Is passing by-value still useful for small pieces of data to be able to have them inlined in TaskRun/PipelineRun statuses?
-### N Configmaps Per TaskRun with Patch Merges (c).
+### N Configmaps Per TaskRun with Patch Merges (c).
- As the TaskRun Pod proceeds, the injected entrypoint would write result data from `/tekton/results/foo` to the ConfigMap. After a TaskRun completes, the TaskRun controller would read the associated ConfigMap data and copy it into the TaskRun’s status. The ConfigMap is then deleted.
- **Create N ConfigMaps** for each of N results, and grant the workload access to write to these results using one of these focused Roles:
diff --git a/teps/0088-result-summaries.md b/teps/0088-result-summaries.md
index 4fb0bc366..482d53816 100644
--- a/teps/0088-result-summaries.md
+++ b/teps/0088-result-summaries.md
@@ -181,7 +181,7 @@ demonstrate the interest in a TEP within the wider Tekton community.
We want to let UIs/CLIs to show high level summaries of Results, e.g. -
| Result | Type | Status | Duration |
-| ------ | ----------- | ------- | -------- |
+|--------|-------------|---------|----------|
| A | PipelineRun | SUCCESS | 30s |
| B | TaskRun | FAILURE | 10s |
| C | CustomRun | SUCCESS | 5s |
diff --git a/teps/0089-nonfalsifiable-provenance-support.md b/teps/0089-nonfalsifiable-provenance-support.md
index fa54a5ea4..fd9114cc6 100644
--- a/teps/0089-nonfalsifiable-provenance-support.md
+++ b/teps/0089-nonfalsifiable-provenance-support.md
@@ -526,11 +526,11 @@ We add the condition type `SignedResultVerified` as a way for the tekton-pipelin
For the condition: `SignedResultVerified`, it has the following the behavior:
-`status`|`reason`|`completionTime` is set|Description
-:-------|:-------|:---------------------:|--------------:
-True|TaskRunResultsVerified|Yes|The `TaskRun` results have been verified through validation of its signatures
-False|TaskRunResultsVerificationFailed|Yes|The `TaskRun` results' signatures failed to verify
-Unknown|AwaitingTaskRunResults|No|Waiting upon `TaskRun` results and signatures to verify
+| `status` | `reason` | `completionTime` is set | Description |
+|:---------|:---------------------------------|:-----------------------:|------------------------------------------------------------------------------:|
+| True | TaskRunResultsVerified | Yes | The `TaskRun` results have been verified through validation of its signatures |
+| False | TaskRunResultsVerificationFailed | Yes | The `TaskRun` results' signatures failed to verify |
+| Unknown | AwaitingTaskRunResults | No | Waiting upon `TaskRun` results and signatures to verify |
### Storing verification data
@@ -677,7 +677,7 @@ Potential mitigations:
## Alternatives
-### Kubernertes Service Account Token Volume Projection
+### Kubernertes Service Account Token Volume Projection
Instead of SPIRE, we could potentially use [Kubernertes Service Account Token Volume Projection](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) for signing.
This is a form of keyless signing, which is described in detail in [Zero-friction “keyless signing” with Kubernetes](https://chainguard.dev/posts/2021-11-03-zero-friction-keyless-signing) by mattmoor@.
diff --git a/teps/0090-matrix.md b/teps/0090-matrix.md
index da6a7e58c..ab25af777 100644
--- a/teps/0090-matrix.md
+++ b/teps/0090-matrix.md
@@ -271,7 +271,7 @@ my repository and produces a `Result` that is used to dynamically execute `TaskR
Read more in [user experience report #1][kaniko-example-1] and [user experience report #2][kaniko-example-2].
-#### 2. Monorepo Build
+#### 2. Monorepo Build
As a `Pipeline` author, I have several components (dockerfiles/packages/services) in my repository.
@@ -402,7 +402,7 @@ repository and produces a `Result` that is used to dynamically execute the `Task
test-code-analysis test-unit-tests e2e-tests
```
-#### 5. Test Sharding
+#### 5. Test Sharding
As a `Pipeline` author, I have a large test suite that's slow (e.g. browser based tests) and I need to speed it up.
I need to split up the test suite into groups, run the tests separately, then combine the results.
@@ -526,7 +526,7 @@ GitHub Actions workflows syntax also allows users to:
Read more in the [documentation][github-actions].
-#### Jenkins
+#### Jenkins
Jenkins allows users to define a configuration `matrix` to specify what steps to duplicate. It also allows users to
exclude certain combinations in the `matrix`
@@ -586,7 +586,7 @@ pipeline {
Read more in the [documentation][jenkins-docs] and related [blog][jenkins-blog].
-#### Argo Workflows
+#### Argo Workflows
Argo Workflows allows users to iterate over:
- a list of items as static inputs
@@ -718,7 +718,7 @@ If needed, we can also explore providing more granular controls for maximum numb
or `Runs` from `Matrices` - either at `PipelineRun`, `Pipeline` or `PipelineTask` levels - later.
This is an option we can pursue after gathering user feedback - it's out of scope for this TEP.
-## Design
+## Design
In this section, we go into the details of the `Matrix` in relation to:
@@ -1060,7 +1060,7 @@ Producing `Results` from fanned out `PipelineTasks` will not be in the initial i
After [TEP-0075: Object Parameters and Results][tep-0075] and [TEP-0076: Array Results][tep-0076]
have landed, we will design how to support `Results` from fanned out `PipelineTasks`.
-### Execution Status
+### Execution Status
Today, `PipelineTasks` in the `finally` section can access the execution `Status` -
`Succeeded`, `Failed` or `None` - of each `PipelineTask` in the `tasks` section. This
@@ -1615,7 +1615,7 @@ However, this approach has the following disadvantages:
[tep-0075]: ./0075-object-param-and-result-types.md
[tep-0076]: ./0076-array-result-types.md
[tep-0079]: ./0079-tekton-catalog-support-tiers.md
-[tep-0096]: ./0096-pipelines-v1-api.md
+[tep-0096]: ./0096-pipelines-v1.md
[tep-0100]: ./0100-embedded-taskruns-and-runs-status-in-pipelineruns.md
[task-loops]: https://github.com/tektoncd/experimental/tree/main/task-loops
[issue-2050]: https://github.com/tektoncd/pipeline/issues/2050
diff --git a/teps/0091-trusted-resources.md b/teps/0091-trusted-resources.md
index 6bb910a6e..40337c267 100644
--- a/teps/0091-trusted-resources.md
+++ b/teps/0091-trusted-resources.md
@@ -706,11 +706,11 @@ So a `keyref` is needed when signing the pipeline. The signing cli doesn't need
### Options for integrating with remote resolution
-| Method | Pros | Cons |
-| -------- | ----------- | ----------- |
-| Fetch remote resources in validating Webhook | Verification fail fast in webhook | Duplicate work for Resolution, may introduce latency, and one extreme case is that the resource verified may not the the same in reconciler's resolved resource
-| Verify in Controller after resolving resources| No duplicate work for Resolution | The verification cannot fail fast in webhook. The resources may have been stored in etcd and used by other components
-| Verify in Remote Resolution | No duplicate work for Resolution | Verification coupled with Resolution
+| Method | Pros | Cons |
+|------------------------------------------------|-----------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Fetch remote resources in validating Webhook | Verification fail fast in webhook | Duplicate work for Resolution, may introduce latency, and one extreme case is that the resource verified may not the the same in reconciler's resolved resource |
+| Verify in Controller after resolving resources | No duplicate work for Resolution | The verification cannot fail fast in webhook. The resources may have been stored in etcd and used by other components |
+| Verify in Remote Resolution | No duplicate work for Resolution | Verification coupled with Resolution |
In this TEP we propose to proceed with option 2 to do verification in reconciler after remote resolution is done considering the latency of doing remote resolution at admission webhook.
@@ -735,11 +735,11 @@ Use Kyverno for verifying YAML files: This can be used to verify local resources
There are several options:
-| Method | Pros | Cons |
-| -------- | ----------- | ----------- |
-| Update the annotation | Easy to implement | Easy to be mutated by other components
-| Add a new field `TrustedResourcesVerified` into `status` | A dedicated field to reflect the verification | Need api change
-| Add a new condition into the status condition list | Easy to implement, hard to be mutated |Need a custom condition type and make sure it is not overwritten
+| Method | Pros | Cons |
+|----------------------------------------------------------|-----------------------------------------------|------------------------------------------------------------------|
+| Update the annotation | Easy to implement | Easy to be mutated by other components |
+| Add a new field `TrustedResourcesVerified` into `status` | A dedicated field to reflect the verification | Need api change |
+| Add a new condition into the status condition list | Easy to implement, hard to be mutated | Need a custom condition type and make sure it is not overwritten |
In this TEP we propose to add a new condition into the status condition list.
diff --git a/teps/0093-add-sign-verify-subcommand-to-the-cli.md b/teps/0093-add-sign-verify-subcommand-to-the-cli.md
index 3e847e428..a8dc82886 100644
--- a/teps/0093-add-sign-verify-subcommand-to-the-cli.md
+++ b/teps/0093-add-sign-verify-subcommand-to-the-cli.md
@@ -120,11 +120,11 @@ tkn task sign examples/example-task.yaml -K=cosign.key -f=signed.yaml
```
Flags:
-| Flag | ShortFlag | Description |
-|---|---|---|
-| keyFile | K | private key file path |
-| kmsKey | m | kms key path |
-| targetFile | f | Filename of the signed file |
+| Flag | ShortFlag | Description |
+|------------|-----------|-----------------------------|
+| keyFile | K | private key file path |
+| kmsKey | m | kms key path |
+| targetFile | f | Filename of the signed file |
This will read private and unmarshal yaml files to get Tekton CRD (Task/Pipeline), signing function should sign the hashed bytes of the CRD, attach the base64 encoded signature to annotation with key as `tekton.dev/signature`.
@@ -136,10 +136,10 @@ To verify a file:
tkn task verify signed.yaml -K=cosign.pub -d=Task
```
-| Flag | ShortFlag | Description |
-|---|---|---|
-| keyFile | K | public key file path |
-| kmsKey | m | kms key path |
+| Flag | ShortFlag | Description |
+|---------|-----------|----------------------|
+| keyFile | K | public key file path |
+| kmsKey | m | kms key path |
Logs in terminal should tell users whether verification succeed or not.
diff --git a/teps/0094-configuring-resources-at-runtime.md b/teps/0094-configuring-resources-at-runtime.md
index 866b33886..de77f5e69 100644
--- a/teps/0094-configuring-resources-at-runtime.md
+++ b/teps/0094-configuring-resources-at-runtime.md
@@ -33,7 +33,7 @@ authors:
- [Conformance](#conformance)
- [Drawbacks](#drawbacks)
- [Alternatives](#alternatives)
- - [Allow TaskRuns to patch arbitrary fields of Tasks](#allow-s-to-patch-arbitrary-fields-of-s)
+ - [Allow TaskRuns to patch arbitrary fields of Tasks](#allow-taskruns-to-patch-arbitrary-fields-of-tasks)
- [Syntax Option 1: Overriding via TaskSpec](#syntax-option-1-overriding-via-taskspec)
- [Syntax Option 2: JSONPath](#syntax-option-2-jsonpath)
- [Allow resource requirements to be parameterized](#allow-resource-requirements-to-be-parameterized)
diff --git a/teps/0096-pipelines-v1.md b/teps/0096-pipelines-v1.md
index c8ea9f34b..96f92b96a 100644
--- a/teps/0096-pipelines-v1.md
+++ b/teps/0096-pipelines-v1.md
@@ -93,7 +93,7 @@ replaced by a version that is at least as stable (for example, v1beta1 can be co
A deprecated API version must continue to be supported for a length of time based on the following chart.
| API Version | Kubernetes Deprecation Policy | Tekton Deprecation Policy |
-|:----------- |:----------------------------- |:------------------------- |
+|:------------|:------------------------------|:--------------------------|
| Alpha | 0 releases | 0 months |
| Beta | 9 months or 3 releases | 9 months |
@@ -135,7 +135,7 @@ must be supported for 12 months from when a new stable API version is created. B
must be accompanied by deprecation warnings and migration instructions from the previous version.
| API Version | Kubernetes Deprecation Policy | Tekton Deprecation Policy |
-|:----------- |:----------------------------- |:------------------------- |
+|:------------|:------------------------------|:--------------------------|
| Alpha | 0 releases | 0 months |
| Beta | 9 months or 3 releases | 9 months |
| V1 | 12 months or 3 releases | 12 months |
@@ -250,7 +250,7 @@ This policy should be updated to include Tekton metrics as part of the API. No o
See [Where should we take ClusterTasks next?](https://github.com/tektoncd/pipeline/issues/4476) for more info.
| CRD | Current level | Proposed level |
-| ----------- | ------------- | -------------- |
+|-------------|---------------|----------------|
| Task | beta | stable |
| TaskRun | beta | stable |
| Pipeline | beta | stable |
@@ -316,15 +316,15 @@ Existing feature flags can be found [here](https://github.com/tektoncd/pipeline/
The feature flag "scope-when-expressions-to-task" is not present in this table,
as its deprecation has already [been announced](https://github.com/tektoncd/pipeline/blob/main/docs/deprecations.md#deprecation-table).
-| Flag | Current Default | Proposed State |
-| --------------------------------------------- | --------------- | -----------------------------------------------------|
-| disable-affinity-assistant | false | default to true |
-| disable-creds-init | false | no change |
-| running-in-environment-with-injected-sidecars | true | no change |
-| require-git-ssh-secret-known-hosts | false | no change |
-| enable-tekton-oci-bundles | false | mark as deprecated and remove in v1 |
-| enable-custom-tasks | false | collapsed under enable-api-fields, requires "beta" |
-| enable-api-fields | stable | default to stable, "beta" option added |
+| Flag | Current Default | Proposed State |
+|-----------------------------------------------|-----------------|----------------------------------------------------|
+| disable-affinity-assistant | false | default to true |
+| disable-creds-init | false | no change |
+| running-in-environment-with-injected-sidecars | true | no change |
+| require-git-ssh-secret-known-hosts | false | no change |
+| enable-tekton-oci-bundles | false | mark as deprecated and remove in v1 |
+| enable-custom-tasks | false | collapsed under enable-api-fields, requires "beta" |
+| enable-api-fields | stable | default to stable, "beta" option added |
### Feature Completeness
diff --git a/teps/0097-breakpoints-for-taskruns-and-pipelineruns.md b/teps/0097-breakpoints-for-taskruns-and-pipelineruns.md
index e614d7c5d..c3c8362e2 100644
--- a/teps/0097-breakpoints-for-taskruns-and-pipelineruns.md
+++ b/teps/0097-breakpoints-for-taskruns-and-pipelineruns.md
@@ -19,7 +19,7 @@ see-also:
- [Requirements](#requirements)
- [TaskRun Proposal](#taskrun-proposal)
- [Breakpoint before/after a step](#breakpoint-beforeafter-a-step)
- - [Breakpoint on failure of a step (already implemented; will be moved to breakpoints.onFailure spec)](#breakpoint-on-failure-of-a-step-already-implemented-will-be-moved-to--spec)
+ - [Breakpoint on failure of a step (already implemented; will be moved to breakpoints.onFailure spec)](#breakpoint-on-failure-of-a-step-already-implemented-will-be-moved-to-breakpointsonfailure-spec)
- [Controlling step lifecycle](#controlling-step-lifecycle)
- [Failure of a Step](#failure-of-a-step)
- [Halting a Step on failure](#halting-a-step-on-failure)
diff --git a/teps/0098-workflows.md b/teps/0098-workflows.md
index 16b583d35..13be5a6d6 100644
--- a/teps/0098-workflows.md
+++ b/teps/0098-workflows.md
@@ -82,7 +82,7 @@ including making it easier to separate notifications and other infrastructure ou
* For example, their CI/CD configuration could live in their repo and could be changed just by editing a file.
* Ops teams or cluster operators will still need to interact with the cluster, and we should provide a way for app engineers
to modify E2E CI/CD configuration directly on the cluster for those who want to.
- * See [User Experience](#user-experience) for more information.
+ * See [User Experience](#user-experience-goals) for more information.
### Future Work
@@ -381,7 +381,7 @@ some pain points have since been addressed by new Triggers features:
- May be addressed by CustomInterceptors, but more investigation is needed.
Building a successful Workflows project may involve addressing some of these gaps in Triggers, and adding new
-features such as [scheduled and polling runs](./0083-scheduled-and-polling-runs-in-tekton.md).
+features such as [scheduled and polling runs](./0083-polling-runs-in-tekton.md).
## Prior Art
@@ -397,7 +397,7 @@ from a connected git repository.
Whenever this configuration changes, Flux will automatically bring the state of their Kubernetes cluster in sync
with the state of the configuration defined in their repository.
- A [POC of Workflows based on FluxCD](https://github.com/tektoncd/experimental/pull/921) found that the `GitRepository` CRD is a close analogue of the repo polling functionality
- described in [TEP-0083](./0083-scheduled-and-polling-runs-in-tekton.md), and is
+ described in [TEP-0083](./0083-polling-runs-in-tekton.md), and is
well suited for CD use cases.
- The Flux `GitHub` receiver can be used to trigger reconciliation between a repo
and a cluster when an event is received from a webhook, but the event body is not
@@ -653,7 +653,7 @@ rewriting all of your Tekton Workflows.
It's possible that the biggest barriers to adoption and easy setup are that there just aren't enough
docs for how to set up Tekton end-to-end and enough catalog Tasks that interact with commonly used platforms.
We could also add more features to Triggers, such as polling and scheduled runs, as proposed in
-[TEP-0083](./0083-scheduled-and-polling-runs-in-tekton.md), and fix [existing pain points](#use-of-triggers)
+[TEP-0083](./0083-polling-runs-in-tekton.md), and fix [existing pain points](#use-of-triggers)
that are preventing some platform builders from building on top of Triggers.
These improvements are useful even outside the context of Workflows. However, we would still need to address the
diff --git a/teps/0100-embedded-taskruns-and-runs-status-in-pipelineruns.md b/teps/0100-embedded-taskruns-and-runs-status-in-pipelineruns.md
index 06bf0cf07..fcb2ea630 100644
--- a/teps/0100-embedded-taskruns-and-runs-status-in-pipelineruns.md
+++ b/teps/0100-embedded-taskruns-and-runs-status-in-pipelineruns.md
@@ -265,7 +265,7 @@ This struct, and `ChildStatusReferences.ConditionChecks`, will be removed once
references for the `conditions`' statuses, because `ConditionCheckStatus`, the only thing
in `PipelineRunConditionCheckStatus` other than the `ConditionName`, isn't replicated
anywhere else, and contains a fairly minimal amount of data - the pod name, start and
-completion times, and a `corev1.ContainerState`. See [the issue for deprecating `Conditions`](issue-3377)
+completion times, and a `corev1.ContainerState`. See [the issue for deprecating `Conditions`][issue-3377]
for more information on the planned removal of `Conditions`.
```go
@@ -790,6 +790,7 @@ support this expansion.
[tep-0096]: https://github.com/tektoncd/community/blob/main/teps/0096-pipelines-v1-api.md
[issue-3140]: https://github.com/tektoncd/pipeline/issues/3140
[issue-3792]: https://github.com/tektoncd/pipeline/issues/3792
+[issue-3377]: https://github.com/tektoncd/pipeline/issues/3377
[issue-82]: https://github.com/tektoncd/results/issues/82
[api-wg]: https://docs.google.com/document/d/17PodAxG8hV351fBhSu7Y_OIPhGTVgj6OJ2lPphYYRpU/edit#heading=h.esbaqjpyouim
[pipelinerunstatus]: https://github.com/tektoncd/pipeline/blob/411d033c5e4bf3409f01b175531cbc1a0a75fadb/pkg/apis/pipeline/v1beta1/pipelinerun_types.go#L290-L296
diff --git a/teps/0102-https-connection-to-triggers-interceptor.md b/teps/0102-https-connection-to-triggers-interceptor.md
index fc041af25..62a7b307c 100644
--- a/teps/0102-https-connection-to-triggers-interceptor.md
+++ b/teps/0102-https-connection-to-triggers-interceptor.md
@@ -105,5 +105,5 @@ At high level below are few implementation details
- [Add changes to run clusterinterceptor as HTTPS](https://github.com/tektoncd/triggers/pull/1333)
-## References
+## References
1. GitHub issue: [#871](https://github.com/tektoncd/triggers/issues/871)
diff --git a/teps/0104-tasklevel-resource-requirements.md b/teps/0104-tasklevel-resource-requirements.md
index 11f4f2ad4..0e49e3823 100644
--- a/teps/0104-tasklevel-resource-requirements.md
+++ b/teps/0104-tasklevel-resource-requirements.md
@@ -291,7 +291,7 @@ spec:
```
| Step name | CPU request | CPU limit |
-| --------- | ----------- | --------- |
+|-----------|-------------|-----------|
| step-1 | 0.5 | N/A |
| step-2 | 0.5 | N/A |
| step-3 | 0.5 | N/A |
@@ -323,7 +323,7 @@ spec:
```
| Step name | CPU request | CPU limit |
-| --------- | ----------- | --------- |
+|-----------|-------------|-----------|
| step-1 | 1 | 3 |
| step-2 | 1 | 3 |
| step-3 | 1 | 3 |
@@ -358,7 +358,7 @@ spec:
```
| Step name | CPU request | CPU limit |
-| --------- | ----------- | --------- |
+|-----------|-------------|-----------|
| step-1 | 0.5 | 2 |
| step-2 | 0.5 | 2 |
| step-3 | 0.5 | 2 |
@@ -400,7 +400,7 @@ spec:
The resulting pod would have the following containers:
| Step/Sidecar name | CPU request | CPU limit |
-| ----------------- | ----------- | --------- |
+|-------------------|-------------|-----------|
| step-1 | 750m | N/A |
| step-2 | 750m | N/A |
| sidecar-1 | 800m | 1 |
@@ -449,7 +449,7 @@ spec:
The resulting pod would have the following containers:
| Step name | CPU request | CPU limit |
-| --------- | ----------- | --------- |
+|-----------|-------------|-----------|
| step-1 | 500m | 750m |
| step-2 | 500m | 750m |
| step-3 | 500m | 750m |
@@ -501,7 +501,7 @@ spec:
The resulting pod would have the following containers:
| Step name | CPU request | CPU limit |
-| --------- | ----------- | --------- |
+|-----------|-------------|-----------|
| step-1 | 600m | 750m |
| step-2 | 600m | 750m |
| step-3 | 600m | 750m |
@@ -541,7 +541,7 @@ spec:
The resulting pod would have the following containers:
| Step name | CPU request | CPU limit |
-| --------- | ----------- | --------- |
+|-----------|-------------|-----------|
| step-1 | 750m | N/A |
| step-2 | 750m | N/A |
@@ -580,7 +580,7 @@ spec:
The resulting pod would have the following containers:
| Step name | CPU request | CPU limit |
-| --------- | ----------- | --------- |
+|-----------|-------------|-----------|
| step-1 | 1 | N/A |
| step-2 | 1 | N/A |
@@ -649,7 +649,7 @@ spec:
The resulting pod would have the following containers:
| Step name | CPU request | CPU limit | Memory request | Memory limit |
-| --------- | ----------- | --------- | -------------- | ------------ |
+|-----------|-------------|-----------|----------------|--------------|
| step-1 | 750m | N/A | 250Mi | 1Gi |
| step-2 | 750m | N/A | 250Mi | 1Gi |
diff --git a/teps/0105-remove-pipeline-v1alpha1-api.md b/teps/0105-remove-pipeline-v1alpha1-api.md
index 13d8a4967..aa25ce4f4 100644
--- a/teps/0105-remove-pipeline-v1alpha1-api.md
+++ b/teps/0105-remove-pipeline-v1alpha1-api.md
@@ -21,7 +21,7 @@ authors:
## Summary
This TEP proposes a clear schedule for the removal of Pipeline's deprecated
-`v1alpha1` API. As we [move towards the stable V1 API](./0096-pipelines-v1-api.md),
+`v1alpha1` API. As we [move towards the stable V1 API](./0096-pipelines-v1.md),
removing the long-deprecated `v1alpha1` API will help clarify migration paths for
users and simplify implementation of the `v1` API.
diff --git a/teps/0106-support-specifying-metadata-per-task-in-runtime.md b/teps/0106-support-specifying-metadata-per-task-in-runtime.md
index 99a736676..a548fc104 100644
--- a/teps/0106-support-specifying-metadata-per-task-in-runtime.md
+++ b/teps/0106-support-specifying-metadata-per-task-in-runtime.md
@@ -29,8 +29,8 @@ authors:
- [Simplicity](#simplicity)
- [Drawbacks](#drawbacks)
- [Alternatives](#alternatives)
- - [Add Metadata under TaskRef in Pipeline](#add-metadata-under--in-)
- - [Create a PipelineTaskRef type](#create-a--type)
+ - [Add Metadata under TaskRef in Pipeline](#add-metadata-under-taskref-in-pipeline)
+ - [Create a PipelineTaskRef type](#create-a-pipelinetaskref-type)
- [Utilize Parameter Substitutions](#utilize-parameter-substitutions)
- [Test Plan](#test-plan)
- [Implementation Pull Requests](#implementation-pull-requests)
diff --git a/teps/0111-propagating-workspaces.md b/teps/0111-propagating-workspaces.md
index c8a871278..cc80d5b0b 100644
--- a/teps/0111-propagating-workspaces.md
+++ b/teps/0111-propagating-workspaces.md
@@ -626,7 +626,7 @@ status:
## Alternatives
-### Propagate all workspaces to all Pipeline Tasks
+### Propagate all workspaces to all Pipeline Tasks
Propagating all `Workspaces` defined at `PipelineRun` down to all the `PipelineTasks` regardless of whether they are used by that `PipelineTask`. However, a workspace may have sensitive data that we don’t want to be accessible to all tasks. This approach is rejected because we only want data available where it is needed. We could remove the unwanted workspaces just before creating the task pod but this method will in turn also propagate workspaces for referenced parameters which we want to avoid because the behavior becomes opaque when users can't see the relationship between Workspaces declared in the referenced resources and the Workspaces supplied in runtime resources.
diff --git a/teps/0112-replace-volumes-with-workspaces.md b/teps/0112-replace-volumes-with-workspaces.md
index f398de16c..6f6796f86 100644
--- a/teps/0112-replace-volumes-with-workspaces.md
+++ b/teps/0112-replace-volumes-with-workspaces.md
@@ -456,7 +456,7 @@ Currently, users may mount any type of volume supported by Kubernetes into their
When considering replacing volumes with Workspaces, we should reconsider what types of volumes are available as Workspace bindings.
There are several options available:
-- [Support all types of volumes as workspace bindings](#support-all-types-of-volumes-in-workspace-binding).
+- [Support all types of volumes as workspace bindings](#support-all-types-of-volumes-in-workspacebinding).
One downside is that there's no clear use case for many of these volume types in the Tekton API.
- Support for [hostPath volumes](#support-hostpath-volumes-in-workspace-bindings).
This helps with advanced docker-in-docker use cases, but isn't necessary for most docker-in-docker use cases and comes with some security concerns.
diff --git a/teps/0114-custom-tasks-beta.md b/teps/0114-custom-tasks-beta.md
index 0f1c57639..19dfc5e7b 100644
--- a/teps/0114-custom-tasks-beta.md
+++ b/teps/0114-custom-tasks-beta.md
@@ -29,7 +29,7 @@ see-also:
- [References and Specifications](#references-and-specifications)
- [Remove Pod Template](#remove-pod-template)
- [Feature Gates](#feature-gates)
- - [New Feature Flag custom-task-version](#new-feature-flag-)
+ - [New Feature Flag custom-task-version](#new-feature-flag-custom-task-version)
- [Existing Feature Gates](#existing-feature-gates)
- [Cancellation](#cancellation)
- [Documentation](#documentation)
@@ -358,7 +358,7 @@ For further details, see [tektoncd/community#523][523], [tektoncd/community#667]
[tep-0002]: 0002-custom-tasks.md
[tep-0105]: 0105-remove-pipeline-v1alpha1-api.md
-[tep-0096]: 0096-pipelines-v1-api.md
+[tep-0096]: 0096-pipelines-v1.md
[tep-0071]: 0071-custom-task-sdk.md
[tep-0061]: 0061-allow-custom-task-to-be-embedded-in-pipeline.md
[tep-0069]: 0069-support-retries-for-custom-task-in-a-pipeline.md
@@ -375,7 +375,7 @@ For further details, see [tektoncd/community#523][523], [tektoncd/community#667]
[pipelines-in-pipelines]: https://github.com/tektoncd/experimental/tree/f60e1cd8ce22ed745e335f6f547bb9a44580dc7c/pipelines-in-pipelines
[pipeline-in-pod]: https://github.com/tektoncd/experimental/tree/f60e1cd8ce22ed745e335f6f547bb9a44580dc7c/pipeline-in-pod
[config]: https://github.com/tektoncd/hub/blob/0ba02511db7a06aef54e2257bf2540be85b53f45/config.yaml
-[hub-cli0]: https://github.com/tektoncd/cli/blob/d826e7a2a17a5f3d3f5b3fe8ac9cff95856627d7/docs/cmd/tkn_hub.md
+[hub-cli]: https://github.com/tektoncd/cli/blob/d826e7a2a17a5f3d3f5b3fe8ac9cff95856627d7/docs/cmd/tkn_hub.md
[4313]: https://github.com/tektoncd/pipeline/issues/4313
[523]: https://github.com/tektoncd/community/pull/523
[667]: https://github.com/tektoncd/community/discussions/667
diff --git a/teps/0115-tekton-catalog-git-based-versioning.md b/teps/0115-tekton-catalog-git-based-versioning.md
index a369e4028..a098bb916 100644
--- a/teps/0115-tekton-catalog-git-based-versioning.md
+++ b/teps/0115-tekton-catalog-git-based-versioning.md
@@ -335,7 +335,7 @@ resources into separate Catalogs where each will have its own versioning.
##### eBay - Catalog with one Task
-[eBay][ebay] shared a repository with a single `Task` for sending Slack messages.
+[eBay][eBay] shared a repository with a single `Task` for sending Slack messages.
The eBay team could modify the repository to meet the organization contract in this TEP - this would make it a Catalog.
@@ -746,7 +746,7 @@ approach of tagging new releases in the Catalogs as is done in GitHub Actions.
We could provide guidelines and recommendations for creating Catalogs e.g. deciding whether to group resources together
instead of splitting them into separate Catalogs. We can explore this in future work.
-### Catlin
+### Catlin
Today, [catlin bump](https://github.com/tektoncd/catlin#bump) command only supports directory-based versioning catalog. We could further extend the [catlin bump](https://github.com/tektoncd/catlin#bump) command to support git-based versioning catalogs (where the command will create a new git tag and a corresponding release note based on the current latest version).
diff --git a/teps/0120-canceling-concurrent-pipelineruns.md b/teps/0120-canceling-concurrent-pipelineruns.md
index 0a0532be0..3f7138dba 100644
--- a/teps/0120-canceling-concurrent-pipelineruns.md
+++ b/teps/0120-canceling-concurrent-pipelineruns.md
@@ -54,7 +54,7 @@ If a new deployment PipelineRun starts while a previous one is still running, th
#### Out of scope
-- Queueing concurrent PipelineRuns; this is covered in [TEP-0132](./0132-queueing-concurrent-pipelineruns.md).
+- Queueing concurrent PipelineRuns; this is covered in [TEP-0132](./0132-queueing-concurrent-runs.md).
### Requirements
diff --git a/teps/0121-refine-retries-for-taskruns-and-customruns.md b/teps/0121-refine-retries-for-taskruns-and-customruns.md
index 2845f4b9e..a93c3a1ed 100644
--- a/teps/0121-refine-retries-for-taskruns-and-customruns.md
+++ b/teps/0121-refine-retries-for-taskruns-and-customruns.md
@@ -25,17 +25,17 @@ see-also:
- [Design Details](#design-details)
- [Timeout per Retry](#timeout-per-retry)
- [Retries in TaskRuns and CustomRuns](#retries-in-taskruns-and-customruns)
- - [Execution Status of a failed pipelineTask with retries](#execution-status-of-a---with-)
+ - [Execution Status of a failed pipelineTask with retries](#execution-status-of-a-failed-pipelinetask-with-retries)
- [Conditions.Succeeded](#conditionssucceeded)
- [RetriesStatus](#retriesstatus)
- [Future Work](#future-work)
- [Alternatives](#alternatives)
- - [1. Implement retries in PipelineRun](#1-implement--in-pipelinerun)
- - [2. Implement retries in TaskRun/Run, use retryAttempts instead of retriesStatus](#2-implement--in-taskrunrun-use--instead-of-)
+ - [1. Implement retries in PipelineRun](#1-implement-retries-in-pipelinerun)
+ - [2. Implement retries in TaskRun/Run, use retryAttempts instead of retriesStatus](#2-implement-retries-in-taskrunrun-use-retryattempts-instead-of-retriesstatus)
- [Two API Changes](#two-api-changes)
- [Two New Labels](#two-new-labels)
- - [How the Retries Works](#how-the--works)
- - [3. Conditions.RetrySucceeded](#3-)
+ - [How the Retries Works](#how-the-retries-works)
+ - [3. Conditions.RetrySucceeded](#3-conditionsretrysucceeded)
- [References](#references)
@@ -115,12 +115,12 @@ Typically, a retry strategy includes:
4. Timeout of each attempt
5. Retry until a certain condition is met
-| | [Retry Action in GA](https://github.com/marketplace/actions/retry-action) | [GitLab Job](https://docs.gitlab.com/ee/ci/yaml/#retry) | [Ansible Task](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html#retrying-a-task-until-a-condition-is-met)| [Concourse Step](https://concourse-ci.org/attempts-step.html#attempts-step) |
-|:---|:---|:---|:---|:---|
-| **When to Retry** | on failure |configurable|[always retry, conditional stop](https://github.com/ansible/ansible/pull/76101) [^ansible-conditional-stop]|configurable|
-| **Attempts amount** |supported|supported|supported|supported|
-| **Timeout for each attempt** |supported|[supported](https://docs.gitlab.com/ee/ci/yaml/#retrywhen)|supported|supported|
-| **Timeout for all attempts** |[supported](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepstimeout-minutes)|-|-|-|
+| | [Retry Action in GA](https://github.com/marketplace/actions/retry-action) | [GitLab Job](https://docs.gitlab.com/ee/ci/yaml/#retry) | [Ansible Task](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html#retrying-a-task-until-a-condition-is-met) | [Concourse Step](https://concourse-ci.org/attempts-step.html#attempts-step) |
+|:-----------------------------|:----------------------------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------|
+| **When to Retry** | on failure | configurable | [always retry, conditional stop](https://github.com/ansible/ansible/pull/76101) [^ansible-conditional-stop] | configurable |
+| **Attempts amount** | supported | supported | supported | supported |
+| **Timeout for each attempt** | supported | [supported](https://docs.gitlab.com/ee/ci/yaml/#retrywhen) | supported | supported |
+| **Timeout for all attempts** | [supported](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepstimeout-minutes) | - | - | - |
Several observations regarding to the feature table above:
@@ -148,16 +148,16 @@ The `PipelineRun` controller does not check for `len(retriesStatus)` to determin
The following table shows how an overall status of a `taskRun` or a `customRun` for a `pipelineTask` with `retries` set to 3:
-| `status` | `reason` |`completionTime` is set | description |
-|----------|-------------|------------------------|------------------------------------------------------------------------------------------------------------|
-| Unknown | Running | No | The `taskRun` has been validated and started to perform its work. |
-| Unknown | ToBeRetried | No | The `taskRun` (zero attempt of a `pipelineTask`) finished executing but failed. It has 3 retries pending. |
-| Unknown | Running | No | First attempt of a `taskRun` has started to perform its work. |
-| Unknown | ToBeRetried | No | The `taskRun` (first attempt of a `pipelineTask`) finished executing but failed. It has 2 retries pending. |
-| Unknown | Running | No | Second attempt of a `taskRun` has started to perform its work. |
-| Unknown | ToBeRetried | No | The `taskRun` (second attempt of a `pipelineTask`) finished executing but failed. It has 1 retry pending. |
-| Unknown | Running | No | Third attempt of a `taskRun` has started to perform its work. |
-| False | Failed | Yes | The `taskRun` (third attempt of a `pipelineTask`) finished executing but failed. No more retries pending. |
+| `status` | `reason` | `completionTime` is set | description |
+|----------|-------------|-------------------------|------------------------------------------------------------------------------------------------------------|
+| Unknown | Running | No | The `taskRun` has been validated and started to perform its work. |
+| Unknown | ToBeRetried | No | The `taskRun` (zero attempt of a `pipelineTask`) finished executing but failed. It has 3 retries pending. |
+| Unknown | Running | No | First attempt of a `taskRun` has started to perform its work. |
+| Unknown | ToBeRetried | No | The `taskRun` (first attempt of a `pipelineTask`) finished executing but failed. It has 2 retries pending. |
+| Unknown | Running | No | Second attempt of a `taskRun` has started to perform its work. |
+| Unknown | ToBeRetried | No | The `taskRun` (second attempt of a `pipelineTask`) finished executing but failed. It has 1 retry pending. |
+| Unknown | Running | No | Third attempt of a `taskRun` has started to perform its work. |
+| False | Failed | Yes | The `taskRun` (third attempt of a `pipelineTask`) finished executing but failed. No more retries pending. |
Pipeline controller can now rely on `ConditionSucceeded` set to `Failed` after all the retries are exhausted.
diff --git a/teps/0122-complete-build-instructions-and-parameters.md b/teps/0122-complete-build-instructions-and-parameters.md
index 00b0fd1b7..cf497c115 100644
--- a/teps/0122-complete-build-instructions-and-parameters.md
+++ b/teps/0122-complete-build-instructions-and-parameters.md
@@ -114,47 +114,47 @@ This will allow us to create a provenance for a task run as [shown](#provenance-
The table below provides the name and description of the API fields that the Task requires. In addition, it also lists if that information is required, not required, or provided by the provenance. If it is required, it also shows where the information should be provided. Looking at the table below and required [step](#step-specification) information, there are only a handful of fields that are not required for reproducibility. Instead of cherry-picking most of the fields, including the entire taskSpec in the buildConfig section of the provenance is likely the best way to go forward. Additionally, if we update the spec in the future, then chains will not have to be updated correspondingly. The work described in [issue](https://github.com/tektoncd/chains/issues/597) is meant to handle this.
-| | **Metadata** | | |
-| ------ | ------------- | ----- | ----- |
-| **Field Name** | **Description** | **Not Required / Required / Provided by provenance** | **Insert in provenance** |
-| name | Name of the task | Required | |
-| Spec | | | |
-| resources | resources used by steps | Not Required (Deprecated) | |
-| description | description of the task | Not Required | |
-| params | parameters required by task | Provided | |
-| results | results produced by the task | Required(Atleast name, type and properties (in case of object)) | buildConfig |
-| volumes | volume mounted on the container | Required | buildConfig |
-| workspaces | workspace bindings used by the task | Required | buildConfig |
-| steps | Steps performed by the task | Provided | |
-| sidecars | Sidecars running alongside tasks | Required | buildConfig |
-| step template | Specifies a container configuration that will be used as the starting point for all of the Steps in your Task | Required | buildConfig |
+| | **Metadata** | | |
+|----------------|---------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------|--------------------------|
+| **Field Name** | **Description** | **Not Required / Required / Provided by provenance** | **Insert in provenance** |
+| name | Name of the task | Required | |
+| Spec | | | |
+| resources | resources used by steps | Not Required (Deprecated) | |
+| description | description of the task | Not Required | |
+| params | parameters required by task | Provided | |
+| results | results produced by the task | Required(Atleast name, type and properties (in case of object)) | buildConfig |
+| volumes | volume mounted on the container | Required | buildConfig |
+| workspaces | workspace bindings used by the task | Required | buildConfig |
+| steps | Steps performed by the task | Provided | |
+| sidecars | Sidecars running alongside tasks | Required | buildConfig |
+| step template | Specifies a container configuration that will be used as the starting point for all of the Steps in your Task | Required | buildConfig |
### Step Specification
The table below provides the name and description of the API fields that the Step requires. In addition, it also lists if that information is required, not required, or provided by the provenance. If it is required, it also shows where the information should be provided. **Deprecated fields have not been included in the table below.** Like in [Task Specification](#task-specification), almost all fields are either required or provided in the provenance. Therefore for the same reasons, we should include the entire spec in the generated provenance.
-| | **Metadata** | | |
-| ------ | ------------- | ----- | ----- |
-| **Field Name** | **Description** | **Not Required / Required / Provided by provenance** | **Insert in provenance** |
-| name | Name of the step | Not Required | |
-| image | Image name for this step | Provided | |
-| command | Entrypoint array | Provided | |
-| args | Arguments to the entrypoint | Provided | |
-| working Dir | Step’s working directory | Required | buildConfig |
-| EnvFrom | List of sources to populate env variables | Required | buildConfig |
-| Env | List of env variables to set in the container | Required | buildConfig |
-| Resources | Compute resources required by this step | Required | buildConfig |
-| VolumeMounts | Volumes to mount in the step’s filesystem | Required | buildConfig |
-| VolumeDevices | List of block devices to be used by the step | Required | buildConfig |
-| ImagePullPolicy | Image Pull Policy | Required | buildConfig |
-| Security Context | security options the step should run with | Required | buildConfig |
-| Script | Contents of an executable file to execute | Provided | |
-| Timeout | Time after which the step times out | Required | buildConfig |
-| Workspaces | list of workspaces from the task that the step wants exclusive access to | Required | buildConfig |
-| OnError | behavior of the container on error | Required | buildConfig |
-| StdOut Config | config of the stdout stream | Required | buildConfig |
-| StdErr Config | config of the stderr stream | Required | buildConfig |
+| | **Metadata** | | |
+|------------------|--------------------------------------------------------------------------|------------------------------------------------------|--------------------------|
+| **Field Name** | **Description** | **Not Required / Required / Provided by provenance** | **Insert in provenance** |
+| name | Name of the step | Not Required | |
+| image | Image name for this step | Provided | |
+| command | Entrypoint array | Provided | |
+| args | Arguments to the entrypoint | Provided | |
+| working Dir | Step’s working directory | Required | buildConfig |
+| EnvFrom | List of sources to populate env variables | Required | buildConfig |
+| Env | List of env variables to set in the container | Required | buildConfig |
+| Resources | Compute resources required by this step | Required | buildConfig |
+| VolumeMounts | Volumes to mount in the step’s filesystem | Required | buildConfig |
+| VolumeDevices | List of block devices to be used by the step | Required | buildConfig |
+| ImagePullPolicy | Image Pull Policy | Required | buildConfig |
+| Security Context | security options the step should run with | Required | buildConfig |
+| Script | Contents of an executable file to execute | Provided | |
+| Timeout | Time after which the step times out | Required | buildConfig |
+| Workspaces | list of workspaces from the task that the step wants exclusive access to | Required | buildConfig |
+| OnError | behavior of the container on error | Required | buildConfig |
+| StdOut Config | config of the stdout stream | Required | buildConfig |
+| StdErr Config | config of the stderr stream | Required | buildConfig |
### TaskRef
@@ -165,24 +165,24 @@ TaskRef is useful for references to existing tasks on the cluster or remote task
The table below provides the name and description of the API fields that the TaskRun requires. In addition, it also lists if that information is required, not required, or provided by the provenance. If it is required, it also shows where the information should be provided. Note that since task run provides information during runtime, most of the information is contained in the **invocation.Parameters** section of the [provenance](#provenance-for-executed-taskrun).
-| | **Metadata** | | |
-| ------ | ------------- | ----- | ----- |
-| **Field Name** | **Description** | **Not Required / Required / Provided by provenance** | **Insert in provenance** |
-| name| Name of the task run| Not required for completeness | |
-| | **Spec** | | |
-| resources | resources used by task | Deprecated but required if using older tekton version | invocation.Parameters |
-| service account name | name of the service account | Required | invocation.Parameters |
-| params | parameter values provided by taskrun | Provided | invocation.Parameters |
-| workspaces | workspaces used by the task | Required | invocation.Parameters |
-| pod template | | Required | invocation.Parameters |
-| Timeout | time in which a task should complete | Required for completeness | invocation.Parameters |
-| StepOverrides | Override Step configuration specified in a Task. Currently we can override compute resources. | Required for completeness | invocation.Parameters |
-| SidecarOverrides | Override Sidecar configuration specified in a Task. Currently we can override compute resources. | Required for completeness | invocation.Parameters |
-| ComputeResources | Configure compute resources required by the steps in the task. | Required (because this could also indicate a minimum amount of resources required for the task run.) | invocation.Parameters |
-| [TaskSpec](#task-specification) | Specification of the resolved task | See [spec](#task-specification) | buildConfig |
-| [TaskRef](#taskref) | Details of the referenced task | Not Required (Since we save the complete TaskSpec even that of a remote task) | |
-| | **Status** | | |
-| Task Results | Results produced by the task run | Not Required since this is an output | |
+| | **Metadata** | | |
+|---------------------------------|--------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------|--------------------------|
+| **Field Name** | **Description** | **Not Required / Required / Provided by provenance** | **Insert in provenance** |
+| name | Name of the task run | Not required for completeness | |
+| | **Spec** | | |
+| resources | resources used by task | Deprecated but required if using older tekton version | invocation.Parameters |
+| service account name | name of the service account | Required | invocation.Parameters |
+| params | parameter values provided by taskrun | Provided | invocation.Parameters |
+| workspaces | workspaces used by the task | Required | invocation.Parameters |
+| pod template | | Required | invocation.Parameters |
+| Timeout | time in which a task should complete | Required for completeness | invocation.Parameters |
+| StepOverrides | Override Step configuration specified in a Task. Currently we can override compute resources. | Required for completeness | invocation.Parameters |
+| SidecarOverrides | Override Sidecar configuration specified in a Task. Currently we can override compute resources. | Required for completeness | invocation.Parameters |
+| ComputeResources | Configure compute resources required by the steps in the task. | Required (because this could also indicate a minimum amount of resources required for the task run.) | invocation.Parameters |
+| [TaskSpec](#task-specification) | Specification of the resolved task | See [spec](#task-specification) | buildConfig |
+| [TaskRef](#taskref) | Details of the referenced task | Not Required (Since we save the complete TaskSpec even that of a remote task) | |
+| | **Status** | | |
+| Task Results | Results produced by the task run | Not Required since this is an output | |
### Configuration Feature Flags
diff --git a/teps/0125-add-credential-filter-to-entrypoint-logger.md b/teps/0125-add-credential-filter-to-entrypoint-logger.md
index d79158a2c..1fa199cf3 100644
--- a/teps/0125-add-credential-filter-to-entrypoint-logger.md
+++ b/teps/0125-add-credential-filter-to-entrypoint-logger.md
@@ -154,7 +154,7 @@ env:
The secret key reference is the trigger to detect an environment variable that contains a secret
and that needs to be redacted.
-### Secrets mounted as Files
+### Secrets mounted as Files
Secrets can also be mounted into pods via files in different ways. The following pod
syntax should be supported in the secret detection logic.
diff --git a/teps/0128-scheduled-runs.md b/teps/0128-scheduled-runs.md
index 7405bd7d8..9d5f85fc4 100644
--- a/teps/0128-scheduled-runs.md
+++ b/teps/0128-scheduled-runs.md
@@ -31,7 +31,7 @@ collaborators: []
- [Security](#security)
- [Drawbacks](#drawbacks)
- [Alternatives](#alternatives)
- - [ScheduledTrigger CRD with fixed event body](#crontrigger-crd-with-fixed-event-body)
+ - [ScheduledTrigger CRD with fixed event body](#scheduledtrigger-crd-with-fixed-event-body)
- [Add schedule to Trigger](#add-schedule-to-trigger)
- [Add schedule to EventListener](#add-schedule-to-eventlistener)
- [Create a PingSource](#create-a-pingsource)
diff --git a/teps/0130-pipeline-level-service.md b/teps/0130-pipeline-level-service.md
index 63df93476..aad5ae244 100644
--- a/teps/0130-pipeline-level-service.md
+++ b/teps/0130-pipeline-level-service.md
@@ -17,7 +17,6 @@ collaborators: []
- [Docker builds](#docker-builds)
- [Other uses for this feature](#other-uses-for-this-feature)
- [Goals](#goals)
- - [Non-Goals](#non-goals)
- [Requirements](#requirements)
- [Related features in other CI/CD systems](#related-features-in-other-cicd-systems)
- [User Experience](#user-experience)
diff --git a/teps/0131-tekton-conformance-policy.md b/teps/0131-tekton-conformance-policy.md
index 4b56f18d1..32834528f 100644
--- a/teps/0131-tekton-conformance-policy.md
+++ b/teps/0131-tekton-conformance-policy.md
@@ -24,7 +24,7 @@ collaborators: ['@dibyom@', '@vdemeester@']
- [Conformance Test Suites](#conformance-test-suites)
- [Q&A](#qa)
- [1. Do field requirements mean the same for Tekton users and vendors?](#1-do-field-requirements-mean-the-same-for-tekton-users-and-vendors)
- - [2 Tekton Conformance Policy (this doc) v.s. Tekton API Compatibility Policy.](#2-tekton-conformance-policy-this-doc-vs-tekton-api-compatibility-policy)
+ - [2 Tekton Conformance Policy (this doc) v.s. Tekton API Compatibility Policy.](#2-tekton-conformance-policy-this-doc-vs-tekton-api-compatibility-policytekton-api-compatibility-policy)
- [3. Do we only include GA primitives in the conformance policy?](#3-do-we-only-include-ga-primitives-in-the-conformance-policy)
- [4. Should we define the Conformance Policy per Tekton Services?](#4-should-we-define-the-conformance-policy-per-tekton-services)
- [Open Questions](#open-questions)
@@ -146,7 +146,7 @@ Worth noting that even if we bump up the policy version, vendors can still claim
### Policy Update Procedure
* **Open a PR** to propose the update.
-* **The PR** must be approved by more than half of [the project OWNERS][project owners] (i.e. 50% + 1) when it involves actual requirements changes (as opposed to typo/grammar fixing).
+* **The PR** must be approved by more than half of [the project OWNERS][Project OWNERs] (i.e. 50% + 1) when it involves actual requirements changes (as opposed to typo/grammar fixing).
* **Update Notice** ahead of time.
* Nice to have: conformance test kit can pop up the update notice when vendors run it.
* How long do we want the update notice to be ahead of is an open question.
@@ -155,7 +155,7 @@ Worth noting that even if we bump up the policy version, vendors can still claim
#### Conformance Test Suites
-We can follow "[duck test][duck test]", we provide inputs (YAMLs including all required fields) and outputs (status, results etc.) to see if vendors meet the requirements (vendors will need to convert the YAMLs to the format they support). Vendors are required to open a PR containing an instruction doc for reproducing the test result, and the community reviews and approves the PR (Borrowed the idea from [Kubernetes Conformance Test][Kubernetes Conformance Test]). This is a one-time test, but the test result MUST be reproducible while the Conformance claim is valid.
+We can follow "[duck test][Duck Test]", we provide inputs (YAMLs including all required fields) and outputs (status, results etc.) to see if vendors meet the requirements (vendors will need to convert the YAMLs to the format they support). Vendors are required to open a PR containing an instruction doc for reproducing the test result, and the community reviews and approves the PR (Borrowed the idea from [Kubernetes Conformance Test][Kubernetes Conformance Test]). This is a one-time test, but the test result MUST be reproducible while the Conformance claim is valid.
### Q&A
#### 1. Do field requirements mean the same for Tekton users and vendors?
diff --git a/teps/0136-capture-traces-for-task-pod-events.md b/teps/0136-capture-traces-for-task-pod-events.md
index a69db1751..9ff2b0b58 100644
--- a/teps/0136-capture-traces-for-task-pod-events.md
+++ b/teps/0136-capture-traces-for-task-pod-events.md
@@ -29,7 +29,6 @@ collaborators: []
- [Drawbacks](#drawbacks)
- [Implementation Plan](#implementation-plan)
- [Test Plan](#test-plan)
- - [Upgrade and Migration Strategy](#upgrade-and-migration-strategy)
- [Implementation Pull Requests](#implementation-pull-requests)
- [References](#references)
diff --git a/teps/0137-cloudevents-controller.md b/teps/0137-cloudevents-controller.md
index cfa35f84d..24566b28c 100644
--- a/teps/0137-cloudevents-controller.md
+++ b/teps/0137-cloudevents-controller.md
@@ -151,15 +151,15 @@ The external controllers may only rely on the information available in the statu
and the list of events in the cache, so the events sent will have to be slightly adapted
accordingly:
-| Resource | Condition | Reason | Current Event | New Event | CDEvent | Notes |
-|---------------|-----------|-----------|----------------|-----------|----------|-------|
-| Any | None | None | None | `queued` | `queued` | When the resource has no status, we know that it has been queued, but we don't know when the main controller will pick it up|
-| Any | `Unknown` | `Started` | `started` | `started` | `started` | The `Started` reason will only be visible by the controller is the main controller was not able to start running its resources in the same reconcile cycle |
-| `TaskRun`, `PipelineRun` | `Unknown` | `Running` | `running` | `started`, `running` or None | `started` or None | If the `started` event was not sent yet, it is sent. If the `running` event was not sent yet, it is sent. If both events were sent already, the `running` event is sent only if there was a change in the `Condition` compared to the last `running` event sent |
-| `TaskRun`, `PipelineRun` | `Unknown` | Any but `Running` | `unknown` | `started`, `unknown` or None | `started` or None | If the `started` event was not sent yet, it is sent. If the `unknown` event was not sent yet, it is sent. If both events were sent already, the `unknown` event is sent only if there was a change in the `Condition` compared to the last `unknown` event sent |
-| `CustomRun` | `Unknown` | Any | `running` | `started`, `running` | `started` or None | If the `started` event was not sent yet, it is sent. We cannot make assumptions about how `Reason` and `Message` are used by the custom run controller, so always send a `running` event |
-| Any | `Succeed` | Any | `successful` | `successful` | `finished` | The `finished` CDEvent include the `Condition` in the `outcome` field |
-| Any | `Failed` | Any | `failed` | `failed` | `finished` | The `finished` CDEvent include the `Condition` in the `outcome` field |
+| Resource | Condition | Reason | Current Event | New Event | CDEvent | Notes |
+|--------------------------|-----------|-------------------|---------------|------------------------------|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Any | None | None | None | `queued` | `queued` | When the resource has no status, we know that it has been queued, but we don't know when the main controller will pick it up |
+| Any | `Unknown` | `Started` | `started` | `started` | `started` | The `Started` reason will only be visible by the controller is the main controller was not able to start running its resources in the same reconcile cycle |
+| `TaskRun`, `PipelineRun` | `Unknown` | `Running` | `running` | `started`, `running` or None | `started` or None | If the `started` event was not sent yet, it is sent. If the `running` event was not sent yet, it is sent. If both events were sent already, the `running` event is sent only if there was a change in the `Condition` compared to the last `running` event sent |
+| `TaskRun`, `PipelineRun` | `Unknown` | Any but `Running` | `unknown` | `started`, `unknown` or None | `started` or None | If the `started` event was not sent yet, it is sent. If the `unknown` event was not sent yet, it is sent. If both events were sent already, the `unknown` event is sent only if there was a change in the `Condition` compared to the last `unknown` event sent |
+| `CustomRun` | `Unknown` | Any | `running` | `started`, `running` | `started` or None | If the `started` event was not sent yet, it is sent. We cannot make assumptions about how `Reason` and `Message` are used by the custom run controller, so always send a `running` event |
+| Any | `Succeed` | Any | `successful` | `successful` | `finished` | The `finished` CDEvent include the `Condition` in the `outcome` field |
+| Any | `Failed` | Any | `failed` | `failed` | `finished` | The `finished` CDEvent include the `Condition` in the `outcome` field |
Since the logic for sending events depends on the content of the cache, it's important
for the cache to be updated **in order**.
@@ -505,14 +505,14 @@ interface to let users specify the data required and let Tekton send the events.
Alternatively, events can be sent by the user directly, which is possible today. It gives
users maximum flexibility but it also leaves the heavy-lifting of sending events to them.
-| `TaskRun`/`CustomRun` | Controlled by | Trigger | Data Available | Example Events |
-|:----------------------|:-------------:|:-------:|:--------------:|:--------------:|
-| Before Start | User | Dedicated resource in the Pipeline | Used defined | Any |
-| Start | Tekton | Resource Created | Annotations, Parameters | Build Started, TestSuiteRun Started |
-| Running | Tekton | Condition Changed, Unknown | Annotations, Parameters | |
-| Running | User | Event requested by user | Any data available in the step context | Any |
-| End | Tekton | Condition Changed, True or False | Annotations, Parameters, Results | Build Finished, Artifact Packaged, Service Deployed |
-| After End | User | Dedicated resource in the Pipeline | Any available in the context, results from previous Tasks| Any |
+| `TaskRun`/`CustomRun` | Controlled by | Trigger | Data Available | Example Events |
+|:----------------------|:-------------:|:----------------------------------:|:---------------------------------------------------------:|:---------------------------------------------------:|
+| Before Start | User | Dedicated resource in the Pipeline | Used defined | Any |
+| Start | Tekton | Resource Created | Annotations, Parameters | Build Started, TestSuiteRun Started |
+| Running | Tekton | Condition Changed, Unknown | Annotations, Parameters | |
+| Running | User | Event requested by user | Any data available in the step context | Any |
+| End | Tekton | Condition Changed, True or False | Annotations, Parameters, Results | Build Finished, Artifact Packaged, Service Deployed |
+| After End | User | Dedicated resource in the Pipeline | Any available in the context, results from previous Tasks | Any |
#### User Interface
diff --git a/teps/0138-decouple-api-and-feature-versioning.md b/teps/0138-decouple-api-and-feature-versioning.md
index e3a93baa4..a58e127b4 100644
--- a/teps/0138-decouple-api-and-feature-versioning.md
+++ b/teps/0138-decouple-api-and-feature-versioning.md
@@ -25,7 +25,8 @@ authors:
- [Per feature flag for new api-driven features](#per-feature-flag-for-new-api-driven-features)
- [Sunset `enable-api-fields` after existing features stabilize](#sunset-`enable-api-fields`-after-existing-features-stabilize)
- [Design Evaluation](#design-evaluation)
- - [Pros and cons](#pros-and-cons)
+ - [Pros](#pros)
+ - [Cons](#cons)
- [Alternatives](#alternatives)
- [Per feature flag with new value for `enable-api-fields` `none`](#per-feature-flag-with-new-value-for-`enable-api-fields`-none)
- [New `legacy-enable-beta-features-by-default` flag](#new-legacy-enable-beta-features-by-default-flag)
@@ -165,11 +166,11 @@ See [implementation plan](#implementation-plan) for more details on the PerFeatu
All **new** features can only be enabled via per-feature flags. When they first get introduced as `alpha`, they will be disabled by default. When new features get promoted to `stable`, they will be enabled by default according to the following table:
-| Feature stability level | Default |
-| ----------------------- | -------- |
-| Stable | Enabled; Cannot be disabled |
-| Beta | Disabled |
-| Alpha | Disabled |
+| Feature stability level | Default |
+|-------------------------|-----------------------------|
+| Stable | Enabled; Cannot be disabled |
+| Beta | Disabled |
+| Alpha | Disabled |
Note that per-feature flags that have stabilized cannot be disabled. We will deprecate the per-feature flag after it has become stable and then remove it eventually after the deprecation period according to the API compatibility policy. We will give deprecation and later removel notice of the per-feature flags via release notes after their promotion to `stable`. Cluster operators who do not want such opt-in features would have enough notice to implement admission controllers on their own to disable the feature.
For example, when a new future feature `pipeline-in-pipeline` becomes stable in v0.55, it would be enabled by default and cannot be disabled after the release. We would need to include in the release note of v0.55 that we are enabling the `pipeline-in-pipeline` feature by default and deprecating its feature flag. And after the deprecation period, we would remove the feature flag.
@@ -272,21 +273,21 @@ This alternative proposes introducing a new flag `legacy-enable-beta-features-by
This chart would apply to the existing `beta` features (array results, array indexing, object params and results, and remote resolution):
-| enable-api-fields | legacy-enable-beta-features-by-default | enabled in `v1beta1`? | enabled in `v1`? |
-| ------ | ------ | --- | --- |
-| beta | true | yes | yes |
-| beta | false | yes | yes |
-| stable | true | yes | no |
-| stable | false | no | no |
+| enable-api-fields | legacy-enable-beta-features-by-default | enabled in `v1beta1`? | enabled in `v1`? |
+|-------------------|-----------------------------------------|-----------------------|------------------|
+| beta | true | yes | yes |
+| beta | false | yes | yes |
+| stable | true | yes | no |
+| stable | false | no | no |
For new `beta` features(e.g. matrix in the future):
-| enable-api-fields | legacy-enable-beta-features-by-default | enabled in `v1beta1`? | enabled in `v1`? |
-| ------ | ------ | --- | --- |
-| beta | true | yes | yes |
-| beta | false | yes | yes |
-| stable | true | no | no |
-| stable | false | no | no |
+| enable-api-fields | legacy-enable-beta-features-by-default | enabled in `v1beta1`? | enabled in `v1`? |
+|-------------------|-----------------------------------------|-----------------------|------------------|
+| beta | true | yes | yes |
+| beta | false | yes | yes |
+| stable | true | no | no |
+| stable | false | no | no |
Once all existing `beta` features become `stable`, `legacy-enable-beta-features-by-default` can be removed. We will deprecate and then remove `legacy-enable-beta-features-by-default` and use `stable` `enable-api-fields`. We would default true for the new flag. After 9 months, we would default `enable-api-fields` to `stable` to preserve the existing behavior.
@@ -341,11 +342,11 @@ type FeatureFlag struct {
We plan to retain the existing testing matrix for fields at `alpha`, `beta` and `stable`. With the addition of per-feature flags for new features, it would look as follows:
-| |enable-api-fields|Per feature flags|Integration tests|
-| -- | -- | -- | -- |
-|Opt-in stable| stable|Turn OFF all per feature flags|Run all stable e2e tests.|
-|Opt-in beta| beta|Turn ON all beta per-feature flags|Run all beta e2e tests.|
-|Opt-in alpha| alpha|Turn ON all per-feature flags (alpha and beta)|Run all alpha e2e tests.|
+| | enable-api-fields | Per feature flags | Integration tests |
+|---------------|-------------------|------------------------------------------------|---------------------------|
+| Opt-in stable | stable | Turn OFF all per feature flags | Run all stable e2e tests. |
+| Opt-in beta | beta | Turn ON all beta per-feature flags | Run all beta e2e tests. |
+| Opt-in alpha | alpha | Turn ON all per-feature flags (alpha and beta) | Run all alpha e2e tests. |
## Additional CI tests
@@ -358,11 +359,11 @@ We cannot test 2\*\*N combinations of per-feature flags, since that would be too
-||enable-api-fields|Per feature flags|Integration tests|
-| :- | :- | :- | :- |
-|Opt-in stable|Set to stable|All feature flags are OFF by default.
Turn ON one feature flag at a time.
|Run a small number of e2e tests against N combinations. It is not feasible to run the entire e2e test suite against N combinations.| -|Opt-in beta|Set to beta|Turn ON all beta per-feature flags by default.All feature flags are OFF by default.
Turn ON one feature flag at a time.
| Run a small number of e2e tests against N combinations. It is not feasible to run the entire e2e test suite against N combinations. | +| Opt-in beta | Set to beta | Turn ON all beta per-feature flags by default.platforms and browsers](#2-checking-compatibility-of-a-browser-extension-on-various--and-)
+ - [2. Checking compatibility of a browser extension on various platforms and browsers](#2-checking-compatibility-of-a-browser-extension-on-various-platforms-and-browsers)
- [Proposal](#proposal)
- [Design Details](#design-details)
- [Results Cache](#results-cache)
@@ -40,7 +40,7 @@ see-also:
- [Missing Task Results](#missing-task-results)
- [Examples](#examples)
- [1. Build and Deploy Images](#1-build-and-deploy-images)
- - [2. Checking compatibility of a browser extension on various platforms and browsers](#2-checking-compatibility-of-a-browser-extension-on-various--and--1)
+ - [2. Checking compatibility of a browser extension on various platforms and browsers](#2-checking-compatibility-of-a-browser-extension-on-various-platforms-and-browsers-1)
- [Design Evaluation](#design-evaluation)
- [Future Work](#future-work)
- [Consuming Individual or Specific Combinations of Results Produced by a Matrixed PipelineTask](#consuming-individual-or-specific-combinations-of-results-produced-by-a-matrixed-pipelinetask)
diff --git a/teps/0141-platform-context-variables.md b/teps/0141-platform-context-variables.md
index ec7c444ed..5b0e183b6 100644
--- a/teps/0141-platform-context-variables.md
+++ b/teps/0141-platform-context-variables.md
@@ -25,9 +25,6 @@ collaborators: []
- [Proposal](#proposal)
- [Notes and Caveats](#notes-and-caveats)
- [Design Details](#design-details)
- - [TaskRun and PipelineRun syntax](#taskrun-and-pipelinerun-syntax)
- - [Parameter substitution](#parameter-substitution)
- - [Provenance generation](#provenance-generation)
- [Design Evaluation](#design-evaluation)
- [Reusability](#reusability)
- [Simplicity](#simplicity)
diff --git a/working-groups.md b/working-groups.md
index d3f0b733c..44b5178bb 100644
--- a/working-groups.md
+++ b/working-groups.md
@@ -23,7 +23,7 @@ calendar, and should invite tekton-dev@googlegroups.com to working group
meetings.
Recordings are made and posted in the minutes of each meeting.
-These docs and the recordings themselves are visible to [all members of our mailing list](#mailing-list).
+These docs and the recordings themselves are visible to [all members of our mailing list](./contact.md#mailing-list).
The current working groups are:
@@ -46,7 +46,6 @@ The current working groups are:
- [Pipeline](#pipeline)
- [Governing Board / Community](#governing-board--community)
- [Software Supply Chain Security (s3c)](#software-supply-chain-security-s3c)
-- [The goal of this working group is to discuss supply chain security initiatives across Tekton.](#the-goal-of-this-working-group-is-to-discuss-supply-chain-security-initiatives-across-tekton)
- [Data Interface](#data-interface)
- [Results](#results)
@@ -307,24 +306,24 @@ and RedHat's [Pipelines as Code](https://github.com/openshift-pipelines/pipeline
| Forum | [tekton-dev@](https://groups.google.com/forum/#!forum/tekton-dev) | |
| Slack Channels | [#workflows](https://tektoncd.slack.com/messages/workflows) |
-| | Points of Contact | Company | Profile |
-|----------------------------------------------------------|-------------------|---------|--------------------------------------- |
-| 
| Dibyo Mukherjee | Google | [dibyom](https://github.com/dibyom) |
-| 
| Khurram Baig | Red Hat | [khrm](https://github.com/khrm) |
-| 
| Chmouel Boudjnah | Red Hat | [chmouel](https://github.com/chmouel) |
-| 
| Lee Bernick | Google | [lbernick](https://github.com/lbernick)|
+| | Points of Contact | Company | Profile |
+|----------------------------------------------------------|-------------------|---------|-----------------------------------------|
+| | Dibyo Mukherjee | Google | [dibyom](https://github.com/dibyom) |
+| | Khurram Baig | Red Hat | [khrm](https://github.com/khrm) |
+| | Chmouel Boudjnah | Red Hat | [chmouel](https://github.com/chmouel) |
+| | Lee Bernick | Google | [lbernick](https://github.com/lbernick) |
## Pipeline
This is the working group for [`tektoncd/pipeline`](https://github.com/tektoncd/pipeline).
Connecting to the Meeting VC requires a Zoom account.
-| Artifact | Link |
-|----------|-------------------------------------------------------------------|
-| Forum | [tekton-dev@](https://groups.google.com/forum/#!forum/tekton-dev) |
-| Meeting Notes | [Notes](https://docs.google.com/document/d/1AfJfdyd1JN2P4haBdYOxEn6SMENMgvQF9ps7iF2QSG0/edit) |
-| Slack Channel | [#pipeline-dev](https://tektoncd.slack.com/messages/pipeline-dev) |
-| Community Meeting VC | [https://zoom.us/j/98272582734?pwd=OTBVMWJIbVJZcUU3WnlodTEvVS9PUT09](https://zoom.us/j/98272582734?pwd=OTBVMWJIbVJZcUU3WnlodTEvVS9PUT09) |
+| Artifact | Link |
+|----------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Forum | [tekton-dev@](https://groups.google.com/forum/#!forum/tekton-dev) |
+| Meeting Notes | [Notes](https://docs.google.com/document/d/1AfJfdyd1JN2P4haBdYOxEn6SMENMgvQF9ps7iF2QSG0/edit) |
+| Slack Channel | [#pipeline-dev](https://tektoncd.slack.com/messages/pipeline-dev) |
+| Community Meeting VC | [https://zoom.us/j/98272582734?pwd=OTBVMWJIbVJZcUU3WnlodTEvVS9PUT09](https://zoom.us/j/98272582734?pwd=OTBVMWJIbVJZcUU3WnlodTEvVS9PUT09) |
| Community Meeting Calendar | Tuesday every other week, 09:30a-10:00a PST 
| Emil Natan | Red Hat | [enarha](https://github.com/enarha) |
| 
| Avinal Kumar | Red Hat | [avinal](https://github.com/avinal) |
| 
| Sayan Biswas | Red Hat | [sayan-biswas](https://github.com/sayan-biswas) |