Update docs to use v1beta1 🙃

Update the `docs/` folder to use `v1beta1` struct when possible instead of `v1alpha1`. This is a follow-up to "expose v1beta1" pull-request and is required for the next release. Signed-off-by: Vincent Demeester <[email protected]>
tektoncd · Mar 9, 2020 · f3fe8e8 · f3fe8e8
1 parent e1d636a
commit f3fe8e8
Show file tree

Hide file tree

Showing 8 changed files with 382 additions and 383 deletions.
diff --git a/docs/auth.md b/docs/auth.md
@@ -68,7 +68,7 @@ aggregates them into their respective files in `$HOME`.
 1. Then use that `ServiceAccount` in your `TaskRun` (in `run.yaml`):
 
 ```yaml
-apiVersion: tekton.dev/v1alpha1
+apiVersion: tekton.dev/v1beta1
 kind: TaskRun
 metadata:
   name: build-push-task-run-2
@@ -81,7 +81,7 @@ spec:
 1. Or use that `ServiceAccount` in your `PipelineRun` (in `run.yaml`):
 
    ```yaml
-   apiVersion: tekton.dev/v1alpha1
+   apiVersion: tekton.dev/v1beta1
    kind: PipelineRun
    metadata:
      name: demo-pipeline
@@ -140,7 +140,7 @@ to authenticate when retrieving any `PipelineResources`.
 1. Then use that `ServiceAccount` in your `TaskRun` (in `run.yaml`):
 
    ```yaml
-   apiVersion: tekton.dev/v1alpha1
+   apiVersion: tekton.dev/v1beta1
    kind: TaskRun
    metadata:
      name: build-push-task-run-2
@@ -153,7 +153,7 @@ to authenticate when retrieving any `PipelineResources`.
 1. Or use that `ServiceAccount` in your `PipelineRun` (in `run.yaml`):
 
    ```yaml
-   apiVersion: tekton.dev/v1alpha1
+   apiVersion: tekton.dev/v1beta1
    kind: PipelineRun
    metadata:
      name: demo-pipeline
@@ -213,7 +213,7 @@ credentials are then used to authenticate when retrieving any
 1. Then use that `ServiceAccount` in your `TaskRun` (in `run.yaml`):
 
 ```yaml
-apiVersion: tekton.dev/v1alpha1
+apiVersion: tekton.dev/v1beta1
 kind: TaskRun
 metadata:
   name: build-push-task-run-2
@@ -226,7 +226,7 @@ spec:
 1. Or use that `ServiceAccount` in your `PipelineRun` (in `run.yaml`):
 
    ```yaml
-   apiVersion: tekton.dev/v1alpha1
+   apiVersion: tekton.dev/v1beta1
    kind: PipelineRun
    metadata:
      name: demo-pipeline
@@ -250,7 +250,7 @@ credentials are then used to authenticate when retrieving any
 
 ## Kubernetes's Docker registry's secret
 
-Kubernetes defines two types of secrets for Docker registries : 
+Kubernetes defines two types of secrets for Docker registries :
 the old format `kubernetes.io/dockercfg` and the new
 `kubernetes.io/dockerconfigjson`. Tekton supports those secrets in
 addition to the one described above.
@@ -278,7 +278,7 @@ addition to the one described above.
 1. Use that `ServiceAccount` in your `TaskRun`:
 
    ```yaml
-   apiVersion: tetkon.dev/v1alpha1
+   apiVersion: tetkon.dev/v1beta1
    kind: TaskRun
    metadata:
      name: build-with-basic-auth

diff --git a/docs/migrating-from-knative-build.md b/docs/migrating-from-knative-build.md
@@ -80,27 +80,27 @@ spec:
 This is the equivalent Task:
 
 ```
-apiVersion: tekton.dev/v1alpha1
+apiVersion: tekton.dev/v1beta1
 kind: Task
 metadata:
   name: go-test
 spec:
-  inputs:
-    params:
-    - name: TARGET
-      description: The Go target to test
-      default: ./...
+  params:
+  - name: TARGET
+    description: The Go target to test
+    default: ./...
 
-    # The Task must operate on some source, e.g., in a Git repo.
-    resources:
+  # The Task must operate on some source, e.g., in a Git repo.
+  resources:
+    inputs:
     - name: source
       type: git
 
   steps:
   - name: go-test  # <-- the step must specify a name.
     image: golang
     workingDir: /workspace/source  # <-- set workingdir
-    command: ['go', 'test', '$(inputs.params.TARGET)']  # <-- specify inputs.params.TARGET
+    command: ['go', 'test', '$(params.TARGET)']  # <-- specify params.TARGET
 ```
 
 ### Build -> TaskRun
@@ -128,18 +128,18 @@ spec:
 This is the equivalent TaskRun:
 
 ```
-apiVersion: tekton.dev/v1alpha1
+apiVersion: tekton.dev/v1beta1
 kind: TaskRun
 metadata:
   name: example-run
 spec:
   taskRef:
     name: go-test
-  inputs:
-    params:
-    - name: TARGET
-      value: ./path/to/test/...
-    resources:
+  params:
+  - name: TARGET
+    value: ./path/to/test/...
+  resources:
+    inputs:
     - name: source
       resourceSpec:
         type: git

diff --git a/docs/pipelineruns.md b/docs/pipelineruns.md
@@ -30,7 +30,7 @@ following fields:
 
 - Required:
   - [`apiVersion`][kubernetes-overview] - Specifies the API version, for example
-    `tekton.dev/v1alpha1`
+    `tekton.dev/vbeta1`
   - [`kind`][kubernetes-overview] - Specify the `PipelineRun` resource object.
   - [`metadata`][kubernetes-overview] - Specifies data to uniquely identify the
     `PipelineRun` resource object, for example a `name`.
@@ -241,7 +241,7 @@ In the following example, the `Task` is defined with a `volumeMount`
 `persistentVolumeClaim`. The Pod will also run as a non-root user.
 
 ```yaml
-apiVersion: tekton.dev/v1alpha1
+apiVersion: tekton.dev/v1beta1
 kind: Task
 metadata:
   name: mytask
@@ -255,7 +255,7 @@ spec:
         - name: my-cache
           mountPath: /my-cache
 ---
-apiVersion: tekton.dev/v1alpha1
+apiVersion: tekton.dev/v1beta1
 kind: Pipeline
 metadata:
   name: mypipeline
@@ -265,7 +265,7 @@ spec:
       taskRef:
         name: mytask
 ---
-apiVersion: tekton.dev/v1alpha1
+apiVersion: tekton.dev/v1beta1
 kind: PipelineRun
 metadata:
   name: mypipelineRun
@@ -383,7 +383,7 @@ spec to mark it as cancelled. Related `TaskRun` instances will be marked as
 cancelled and running Pods will be deleted.
 
 ```yaml
-apiVersion: tekton.dev/v1alpha1
+apiVersion: tekton.dev/v1beta1
 kind: PipelineRun
 metadata:
   name: go-example-git
@@ -394,15 +394,15 @@ spec:
 
 ## LimitRanges
 
-In order to request the minimum amount of resources needed to support the containers 
-for `steps` that are part of a `TaskRun`, Tekton only requests the maximum values for CPU, 
-memory, and ephemeral storage from the `steps` that are part of a TaskRun. Only the max 
-resource request values are needed since `steps` only execute one at a time in a `TaskRun` pod. 
-All requests that are not the max values are set to zero as a result. 
+In order to request the minimum amount of resources needed to support the containers
+for `steps` that are part of a `TaskRun`, Tekton only requests the maximum values for CPU,
+memory, and ephemeral storage from the `steps` that are part of a TaskRun. Only the max
+resource request values are needed since `steps` only execute one at a time in a `TaskRun` pod.
+All requests that are not the max values are set to zero as a result.
 
-When a [LimitRange](https://kubernetes.io/docs/concepts/policy/limit-range/) is present in a namespace 
-with a minimum set for container resource requests (i.e. CPU, memory, and ephemeral storage) where `PipelineRuns` 
-are attempting to run, Tekton will search through all LimitRanges present in the namespace and use the minimum 
+When a [LimitRange](https://kubernetes.io/docs/concepts/policy/limit-range/) is present in a namespace
+with a minimum set for container resource requests (i.e. CPU, memory, and ephemeral storage) where `PipelineRuns`
+are attempting to run, Tekton will search through all LimitRanges present in the namespace and use the minimum
 set for container resource requests instead of requesting 0.
 
 An example `PipelineRun` with a LimitRange is available [here](../examples/v1beta1/pipelineruns/no-ci/limitrange.yaml).

diff --git a/docs/pipelines.md b/docs/pipelines.md
@@ -25,7 +25,7 @@ following fields:
 
 - Required:
   - [`apiVersion`][kubernetes-overview] - Specifies the API version, for example
-    `tekton.dev/v1alpha1`.
+    `tekton.dev/v1beta1`.
   - [`kind`][kubernetes-overview] - Specify the `Pipeline` resource object.
   - [`metadata`][kubernetes-overview] - Specifies data to uniquely identify the
     `Pipeline` resource object, for example a `name`.
@@ -51,9 +51,9 @@ following fields:
         apply to cancellations.
       - [`conditions`](#conditions) - Used when a task is to be executed only if the specified
         conditions are evaluated to be true.
-      - [`timeout`](#timeout) - Specifies timeout after which the `TaskRun` for a Pipeline Task will 
-        fail. There is no default timeout for a Pipeline Task timeout. If no timeout is specified for 
-        the Pipeline Task, the only timeout taken into account for running a `Pipeline` will be a 
+      - [`timeout`](#timeout) - Specifies timeout after which the `TaskRun` for a Pipeline Task will
+        fail. There is no default timeout for a Pipeline Task timeout. If no timeout is specified for
+        the Pipeline Task, the only timeout taken into account for running a `Pipeline` will be a
         [timeout for the `PipelineRun`](https://github.com/tektoncd/pipeline/blob/master/docs/pipelineruns.md#syntax).
 
 [kubernetes-overview]:
@@ -166,7 +166,7 @@ a parameter are optional, and if the `default` field is specified and this
 the `default` value will be used.
 
 ```yaml
-apiVersion: tekton.dev/v1alpha1
+apiVersion: tekton.dev/v1beta1
 kind: Pipeline
 metadata:
   name: pipeline-with-parameters
@@ -190,7 +190,7 @@ spec:
 The following `PipelineRun` supplies a value for `context`:
 
 ```yaml
-apiVersion: tekton.dev/v1alpha1
+apiVersion: tekton.dev/v1beta1
 kind: PipelineRun
 metadata:
   name: pipelinerun-with-parameters
@@ -205,7 +205,7 @@ spec:
 ### Pipeline Tasks
 
 A `Pipeline` will execute a graph of [`Tasks`](tasks.md) (see
-[ordering](#ordering) for how to express this graph). A valid `Pipeline` 
+[ordering](#ordering) for how to express this graph). A valid `Pipeline`
 declaration must include a reference to at least one [`Task`](tasks.md). Each
 `Task` within a `Pipeline` must have a
 [valid](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)
@@ -358,11 +358,11 @@ triggered: a max of two executions.
 
 #### conditions
 
-Sometimes you will need to run tasks only when some conditions are true. The `conditions` field 
+Sometimes you will need to run tasks only when some conditions are true. The `conditions` field
 allows you to list a series of references to [`Conditions`](./conditions.md) that are run before the task
 is run. If all of the conditions evaluate to true, the task is run. If any of the conditions are false,
 the Task is not run. Its status.ConditionSucceeded is set to False with the reason set to  `ConditionCheckFailed`.
-However, unlike regular task failures, condition failures do not automatically fail the entire pipeline 
+However, unlike regular task failures, condition failures do not automatically fail the entire pipeline
 run -- other tasks that are not dependent on the task (via `from` or `runAfter`) are still run.
 
 ```yaml
@@ -380,10 +380,10 @@ tasks:
             resource: source-repo
 ```
 
-In this example, `my-condition` refers to a [Condition](conditions.md) custom resource. The `build-push` 
-task will only be executed if the condition evaluates to true. 
+In this example, `my-condition` refers to a [Condition](conditions.md) custom resource. The `build-push`
+task will only be executed if the condition evaluates to true.
 
-Resources in conditions can also use the [`from`](#from) field to indicate that they 
+Resources in conditions can also use the [`from`](#from) field to indicate that they
 expect the output of a previous task as input. As with regular Pipeline Tasks, using `from`
 implies ordering --  if task has a condition that takes in an output resource from
 another task, the task producing the output resource will run first:
@@ -410,11 +410,11 @@ tasks:
 
 #### Timeout
 
-The Timeout property of a Pipeline Task allows a timeout to be defined for a `TaskRun` that 
-is part of a `PipelineRun`. If the `TaskRun` exceeds the amount of time specified, the `TaskRun` 
-will fail and the `PipelineRun` associated with a `Pipeline` will fail as well. 
+The Timeout property of a Pipeline Task allows a timeout to be defined for a `TaskRun` that
+is part of a `PipelineRun`. If the `TaskRun` exceeds the amount of time specified, the `TaskRun`
+will fail and the `PipelineRun` associated with a `Pipeline` will fail as well.
 
-There is no default timeout for Pipeline Tasks, so a timeout must be specified with a Pipeline Task 
+There is no default timeout for Pipeline Tasks, so a timeout must be specified with a Pipeline Task
 when defining a `Pipeline` if one is needed. An example of a Pipeline Task with a Timeout is shown below:
 
 ```yaml
@@ -426,8 +426,8 @@ spec:
       Timeout: "0h1m30s"
 ```
 
-The Timeout property is specified as part of the Pipeline Task on the `Pipeline` spec. The above 
-example has a timeout of one minute and 30 seconds.  
+The Timeout property is specified as part of the Pipeline Task on the `Pipeline` spec. The above
+example has a timeout of one minute and 30 seconds.
 
 ### Results