From f3fe8e8a77674896d597ef5ae5466290e666acd8 Mon Sep 17 00:00:00 2001 From: Vincent Demeester Date: Mon, 9 Mar 2020 11:53:49 +0100 Subject: [PATCH] =?UTF-8?q?Update=20docs=20to=20use=20v1beta1=20?= =?UTF-8?q?=F0=9F=99=83?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- docs/auth.md | 16 +- docs/migrating-from-knative-build.md | 30 +-- docs/pipelineruns.md | 26 +- docs/pipelines.md | 36 +-- docs/resources.md | 65 +++-- docs/taskruns.md | 138 ++++++----- docs/tasks.md | 350 +++++++++++++-------------- docs/tutorial.md | 104 ++++---- 8 files changed, 382 insertions(+), 383 deletions(-) diff --git a/docs/auth.md b/docs/auth.md index c18f0ff93cc..ee8a8398aac 100644 --- 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 index 2c456c4fd0c..83a218373b0 100644 --- a/docs/migrating-from-knative-build.md +++ b/docs/migrating-from-knative-build.md @@ -80,19 +80,19 @@ 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 @@ -100,7 +100,7 @@ spec: - 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 index 17216a9cc80..c29ac7be709 100644 --- 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 index 8c3d16a443b..71294f10fb1 100644 --- 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 diff --git a/docs/resources.md b/docs/resources.md index 4020a6dd85b..3ad564c96ca 100644 --- a/docs/resources.md +++ b/docs/resources.md @@ -80,7 +80,7 @@ variables such as `path` using the variable substitution syntax below where #### In Task Spec: -For an input resource in a `Task` spec: `shell $(inputs.resources..)` +For an input resource in a `Task` spec: `shell $(resources.inputs..)` Or for an output resource: @@ -99,7 +99,7 @@ $(resources..) #### Accessing local path to resource The `path` key is pre-defined and refers to the local path to a resource on the -mounted volume `shell $(inputs.resources..path)` +mounted volume `shell $(resources.inputs..path)` ### Controlling where resources are mounted @@ -110,14 +110,14 @@ will be initialized under `/workspace`. The following example demonstrates how git input repository could be initialized in `$GOPATH` to run tests: ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: task-with-input namespace: default spec: - inputs: - resources: + resources: + inputs: - name: workspace type: git targetPath: go/src/github.com/tektoncd/pipeline @@ -160,18 +160,17 @@ resource `java-git-resource` (including the war artifact) copied to the destination path `/custom/workspace/`. ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: volume-task namespace: default spec: - inputs: - resources: + resources: + inputs: - name: workspace type: git - outputs: - resources: + outputs: - name: workspace steps: - name: build-war @@ -184,7 +183,7 @@ spec: ``` ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: TaskRun metadata: name: volume-taskrun @@ -192,13 +191,12 @@ metadata: spec: taskRef: name: volume-task - inputs: - resources: + resources: + inputs: - name: workspace resourceRef: name: java-git-resource - outputs: - resources: + outputs: - name: workspace paths: - /custom/workspace/ @@ -234,13 +232,13 @@ for that resource. Resources declared as `optional` in a `Task` does not have be specified in `TaskRun`. ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: task-check-optional-resources spec: - inputs: - resources: + resources: + inputs: - name: git-repo type: git optional: true @@ -250,7 +248,7 @@ Similarly, resources declared as `optional` in a `Pipeline` does not have to be specified in `PipelineRun`. ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata: name: pipeline-build-image @@ -267,10 +265,10 @@ spec: You can refer to different examples demonstrating usage of optional resources in `Task`, `Condition`, and `Pipeline`: -- [Task](../examples/v1alpha1/taskruns/optional-resources.yaml) -- [Cluster Task](../examples/v1alpha1/taskruns/optional-resources-with-clustertask.yaml) -- [Condition](../examples/v1alpha1/pipelineruns/conditional-pipelinerun-with-optional-resources.yaml) -- [Pipeline](../examples/v1alpha1/pipelineruns/demo-optional-resources.yaml) +- [Task](../examples/v1beta1/taskruns/optional-resources.yaml) +- [Cluster Task](../examples/v1beta1/taskruns/optional-resources-with-clustertask.yaml) +- [Condition](../examples/v1beta1/pipelineruns/conditional-pipelinerun-with-optional-resources.yaml) +- [Pipeline](../examples/v1beta1/pipelineruns/demo-optional-resources.yaml) ## Resource Types @@ -542,17 +540,16 @@ exported. For example this build-push task defines the `outputImageDir` for the `builtImage` resource in `/workspace/buildImage` ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: build-push spec: - inputs: - resources: + resources: + inputs: - name: workspace type: git - outputs: - resources: + outputs: - name: builtImage type: image targetPath: /workspace/builtImage @@ -674,14 +671,14 @@ Example usage of the `cluster` resource in a `Task`, using [variable substitution](tasks.md#variable-substitution): ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: deploy-image namespace: default spec: - inputs: - resources: + resources: + inputs: - name: workspace type: git - name: dockerimage @@ -695,8 +692,8 @@ spec: args: - "-c" - kubectl --kubeconfig - /workspace/$(inputs.resources.testcluster.name)/kubeconfig --context - $(inputs.resources.testcluster.name) apply -f /workspace/service.yaml' + /workspace/$(resources.inputs.testcluster.name)/kubeconfig --context + $(resources.inputs.testcluster.name) apply -f /workspace/service.yaml' ``` To use the `cluster` resource with Google Kubernetes Engine, you should use the @@ -940,7 +937,7 @@ The content of an event is for example: Context Attributes, SpecVersion: 0.2 Type: dev.tekton.event.task.successful - Source: /apis/tekton.dev/v1alpha1/namespaces/default/taskruns/pipeline-run-api-16aa55-source-to-image-task-rpndl + Source: /apis/tekton.dev/v1beta1/namespaces/default/taskruns/pipeline-run-api-16aa55-source-to-image-task-rpndl ID: pipeline-run-api-16aa55-source-to-image-task-rpndl Time: 2019-07-04T11:03:53.058694712Z ContentType: application/json diff --git a/docs/taskruns.md b/docs/taskruns.md index f2708014a8d..261d3576edd 100644 --- a/docs/taskruns.md +++ b/docs/taskruns.md @@ -13,7 +13,7 @@ A `TaskRun` runs until all `steps` have completed or until a failure occurs. - [Syntax](#syntax) - [Specifying a `Task`](#specifying-a-task) - - [Input parameters](#input-parameters) + - [Parameters](#parameters) - [Providing resources](#providing-resources) - [Overriding where resources are copied from](#overriding-where-resources-are-copied-from) - [Service Account](#service-account) @@ -37,7 +37,7 @@ following fields: - Required: - [`apiVersion`][kubernetes-overview] - Specifies the API version, for example - `tekton.dev/v1alpha1`. + `tekton.dev/v1beta1`. - [`kind`][kubernetes-overview] - Specify the `TaskRun` resource object. - [`metadata`][kubernetes-overview] - Specifies data to uniquely identify the `TaskRun` resource object, for example a `name`. @@ -51,9 +51,10 @@ following fields: object that enables your build to run with the defined authentication information. When a `ServiceAccount` isn't specified, the `default-service-account` specified in the configmap `config-defaults` will be applied. - - [`inputs`] - Specifies [input parameters](#input-parameters) and - [input resources](#providing-resources) - - [`outputs`] - Specifies [output resources](#providing-resources) + - [`params`](#parameters) - Specifies parameters values + - [`resources`](#providing-resources) - Specifies `PipelineResource` values + - [`inputs`] - Specifies input resources + - [`outputs`] - Specifies output resources - [`timeout`] - Specifies timeout after which the `TaskRun` will fail. If the value of `timeout` is empty, the default timeout will be applied. If the value is set to 0, there is no timeout. You can also follow the instruction [here](#Configuring-default-timeout) @@ -83,8 +84,8 @@ Or you can embed the spec of the `Task` directly in the `TaskRun`: ```yaml spec: taskSpec: - inputs: - resources: + resources: + inputs: - name: workspace type: git steps: @@ -100,17 +101,16 @@ spec: - --destination=gcr.io/my-project/gohelloworld ``` -### Input parameters +### Parameters If a `Task` has [`parameters`](tasks.md#parameters), you can specify values for -them using the `input` section: +them using the `params` section: ```yaml spec: - inputs: - params: - - name: flags - value: -someflag + params: + - name: flags + value: -someflag ``` If a parameter does not have a default value, it must be specified. @@ -126,19 +126,23 @@ They can be provided via references to existing ```yaml spec: - inputs: - resources: + resources: + inputs: - name: workspace resourceRef: name: java-git-resource + outputs: + - name: image + resourceRef: + name: my-app-image ``` Or by embedding the specs of the resources directly: ```yaml spec: - inputs: - resources: + resources: + inputs: - name: workspace resourceSpec: type: git @@ -193,7 +197,7 @@ PersistenceVolumeClaim. The SchedulerName has also been provided to define which dispatch the Pod. The Pod will also run as a non-root user. ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: mytask @@ -208,7 +212,7 @@ spec: - name: my-cache mountPath: /my-cache --- -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: TaskRun metadata: name: mytaskRun @@ -408,13 +412,13 @@ spec: - name: url value: https://github.com/pivotal-nader-ziada/gohelloworld --- -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: read-task spec: - inputs: - resources: + resources: + inputs: - name: workspace type: git steps: @@ -422,15 +426,15 @@ spec: image: ubuntu script: cat workspace/README.md --- -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: TaskRun metadata: name: read-repo-run spec: taskRef: name: read-task - inputs: - resources: + resources: + inputs: - name: workspace resourceRef: name: go-example-git @@ -454,19 +458,19 @@ spec: - name: url value: https://github.com/pivotal-nader-ziada/gohelloworld --- -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: TaskRun metadata: name: build-push-task-run-2 spec: - inputs: - resources: + resources: + inputs: - name: workspace resourceRef: name: go-example-git taskSpec: - inputs: - resources: + resources: + inputs: - name: workspace type: git steps: @@ -488,15 +492,15 @@ a Pipeline Resource Spec but not both. Below is an example where Git Pipeline Resource Spec is provided as input for TaskRun `read-repo`. ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: TaskRun metadata: name: read-repo spec: taskRef: name: read-task - inputs: - resources: + resources: + inputs: - name: workspace resourceSpec: type: git @@ -534,14 +538,14 @@ spec: spec: taskRef: name: dockerfile-build-and-push - inputs: - resources: + params: + - name: IMAGE + value: gcr.io/my-project/rester-tester + resources: + inputs: - name: workspace resourceRef: name: mchmarny-repo - params: - - name: IMAGE - value: gcr.io/my-project/rester-tester ``` Build `googlecloudplatform/cloud-builder`'s `wget` builder: @@ -562,17 +566,17 @@ spec: spec: taskRef: name: dockerfile-build-and-push - inputs: - resources: + params: + - name: IMAGE + value: gcr.io/my-project/wget + # Optional override to specify the subdirectory containing the Dockerfile + - name: DIRECTORY + value: /workspace/wget + resources: + inputs: - name: workspace resourceRef: name: cloud-builder-repo - params: - - name: IMAGE - value: gcr.io/my-project/wget - # Optional override to specify the subdirectory containing the Dockerfile - - name: DIRECTORY - value: /workspace/wget ``` Build `googlecloudplatform/cloud-builder`'s `docker` builder with `17.06.1`: @@ -593,19 +597,19 @@ spec: spec: taskRef: name: dockerfile-build-and-push - inputs: - resources: + params: + - name: IMAGE + value: gcr.io/my-project/docker + # Optional overrides + - name: DIRECTORY + value: /workspace/docker + - name: DOCKERFILE_NAME + value: Dockerfile-17.06.1 + resources: + inputs: - name: workspace resourceRef: name: cloud-builder-repo - params: - - name: IMAGE - value: gcr.io/my-project/docker - # Optional overrides - - name: DIRECTORY - value: /workspace/docker - - name: DOCKERFILE_NAME - value: Dockerfile-17.06.1 ``` #### Using a `ServiceAccount` @@ -613,14 +617,14 @@ spec: Specifying a `ServiceAccount` to access a private `git` repository: ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: TaskRun metadata: name: test-task-with-serviceaccount-git-ssh spec: serviceAccountName: test-task-robot-git-ssh - inputs: - resources: + resources: + inputs: - name: workspace type: git steps: @@ -705,15 +709,15 @@ they exited. ## 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 `TaskRuns` -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 `TaskRuns` +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 `TaskRun` with a LimitRange is available [here](../examples/v1beta1/taskruns/no-ci/limitrange.yaml). diff --git a/docs/tasks.md b/docs/tasks.md index 263d88e1ba3..c611f675a92 100644 --- a/docs/tasks.md +++ b/docs/tasks.md @@ -6,9 +6,11 @@ will run inside a pod on your cluster. A `Task` declares: -- [Inputs](#inputs) -- [Outputs](#outputs) +- [Parameters](#parameters) +- [Resources](#resources) - [Steps](#steps) +- [Workspaces](#workspaces) +- [Results](#results) A `Task` is available within a namespace, and `ClusterTask` is available across entire Kubernetes cluster. @@ -19,12 +21,15 @@ entire Kubernetes cluster. - [Syntax](#syntax) - [Steps](#steps) - [Step script](#step-script) - - [Inputs](#inputs) - - [Outputs](#outputs) - - [Volumes](#volumes) + - [Parameters](#paramaters) + - [Resources](#resources) + - [Inputs](#inputs) + - [Outputs](#outputs) - [Workspaces](#workspaces) - - [Step Template](#step-template) - [Results](#results) + - [Volumes](#volumes) + - [Step Template](#step-template) + - [Sidecars](#sidecars) - [Variable Substitution](#variable-substitution) - [Examples](#examples) - [Debugging Tips](#debugging) @@ -37,7 +42,7 @@ In case of using a ClusterTask, the `TaskRef` kind should be added. The default kind is Task which represents a namespaced Task ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata: name: demo-pipeline @@ -61,7 +66,7 @@ following fields: - Required: - [`apiVersion`][kubernetes-overview] - Specifies the API version, for example - `tekton.dev/v1alpha1`. + `tekton.dev/v1beta`. - [`kind`][kubernetes-overview] - Specify the `Task` resource object. - [`metadata`][kubernetes-overview] - Specifies data to uniquely identify the `Task` resource object, for example a `name`. @@ -71,15 +76,18 @@ following fields: - [`steps`](#steps) - Specifies one or more container images that you want to run in your `Task`. - Optional: - - [`inputs`](#inputs) - Specifies parameters and - [`PipelineResources`](resources.md) needed by your `Task` - - [`outputs`](#outputs) - Specifies [`PipelineResources`](resources.md) - created by your `Task` + - [`params`](#params) - Specifies parameters + - [`resources`](#resources) - Specifies + [`PipelineResources`](resources.md) needed or created by your + `Task`. *Note: this is an alpha field, it is not supported as the + rest of the beta field*. + - [`inputs`](#inputs-resources) - resources needed by your `Task`. + - [`outputs`](#outputs-resources) - resources created by your `Task` + - [`workspaces`](#workspaces) - Specifies paths at which you expect volumes to + be mounted and available - [`results`](#results) - Specifies the result file name where the task can write its result - [`volumes`](#volumes) - Specifies one or more volumes that you want to make available to your `Task`'s steps. - - [`workspaces`](#workspaces) - Specifies paths at which you expect volumes to - be mounted and available - [`stepTemplate`](#step-template) - Specifies a `Container` step definition to use as the basis for all steps within your `Task`. - [`sidecars`](#sidecars) - Specifies sidecar containers to run alongside @@ -92,22 +100,21 @@ The following example is a non-working sample where most of the possible configuration fields are used: ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: example-task-name spec: - inputs: - resources: + params: + - name: pathToDockerFile + type: string + description: The path to the dockerfile to build + default: /workspace/workspace/Dockerfile + resources: + inputs: - name: workspace type: git - params: - - name: pathToDockerFile - type: string - description: The path to the dockerfile to build - default: /workspace/workspace/Dockerfile - outputs: - resources: + outputs: - name: builtImage type: image steps: @@ -116,10 +123,10 @@ spec: args: ["ubuntu-build-example", "SECRETS-example.md"] - image: gcr.io/example-builders/build-example command: ["echo"] - args: ["$(inputs.params.pathToDockerFile)"] + args: ["$(params.pathToDockerFile)"] - name: dockerfile-pushexample image: gcr.io/example-builders/push-example - args: ["push", "$(outputs.resources.builtImage.url)"] + args: ["push", "$(resources.outputs.builtImage.url)"] volumeMounts: - name: docker-socket-example mountPath: /var/run/docker.sock @@ -220,14 +227,7 @@ steps: /bin/my-binary ``` -### Inputs - -A `Task` can declare the inputs it needs, which can be either or both of: - -- [`parameters`](#parameters) -- [input resources](#input-resources) - -#### Parameters +### Parameters Tasks can declare input parameters that must be supplied to the task during a TaskRun. Some example use-cases of this include: @@ -242,63 +242,68 @@ parameter name, `barIsBa$` or `0banana` are not. Each declared parameter has a `type` field, assumed to be `string` if not provided by the user. The other possible type is `array` — useful, for instance, when a dynamic number of compilation flags need to be supplied to a task building an application. When the actual parameter value is supplied, its parsed type is validated against the `type` field. -##### Usage +#### Usage The following example shows how Tasks can be parameterized, and these parameters can be passed to the `Task` from a `TaskRun`. -Input parameters in the form of `$(inputs.params.foo)` are replaced inside of +Input parameters in the form of `$(params.foo)` are replaced inside of the [`steps`](#steps) (see also [variable substitution](#variable-substitution)). The following `Task` declares two input parameters named 'flags' (array) and 'someURL' (string), and uses them in -the `steps.args` list. Array parameters like 'flags' can be expanded inside of an existing array by using star expansion syntax by adding `[*]` to the named parameter as we do below using `$(inputs.params.flags[*])`. +the `steps.args` list. Array parameters like 'flags' can be expanded inside of an existing array by using star expansion syntax by adding `[*]` to the named parameter as we do below using `$(params.flags[*])`. ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: task-with-parameters spec: - inputs: - params: - - name: flags - type: array - - name: someURL - type: string + params: + - name: flags + type: array + - name: someURL + type: string steps: - name: build image: my-builder - args: ["build", "$(inputs.params.flags[*])", "url=$(inputs.params.someURL)"] + args: ["build", "$(params.flags[*])", "url=$(params.someURL)"] ``` The following `TaskRun` supplies a dynamic number of strings within the `flags` parameter: ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: TaskRun metadata: name: run-with-parameters spec: taskRef: name: task-with-parameters - inputs: - params: - - name: flags - value: - - "--set" - - "arg1=foo" - - "--randomflag" - - "--someotherflag" - - name: someURL - value: "http://google.com" + params: + - name: flags + value: + - "--set" + - "arg1=foo" + - "--randomflag" + - "--someotherflag" + - name: someURL + value: "http://google.com" ``` +### Resources + +A `Task` can declare the resources it needs and create, which can be either or both of: + +- [input resources](#input-resources) +- [output resources](#output-resources) + #### Input resources Use input [`PipelineResources`](resources.md) field to provide your `Task` with data or context that is needed by your `Task`. See the [using resources docs](./resources.md#using-resources). -### Outputs +#### Output resources `Task` definitions can include inputs and outputs [`PipelineResource`](resources.md) declarations. If specific set of resources @@ -307,8 +312,8 @@ next Task is expected to be present under the path `/workspace/output/resource_name/`. ```yaml -outputs: - resources: +resources: + outputs: name: storage-gcs type: gcs steps: @@ -335,12 +340,11 @@ directory. After execution of the Task steps, (new) tar file in directory `tar-artifact` resource definition. ```yaml -inputs: - resources: +resources: + inputs: name: tar-artifact targetPath: customworkspace -outputs: - resources: + outputs: name: tar-artifact steps: - name: untar @@ -357,6 +361,48 @@ steps: args: ['-c', 'cd /workspace/tar-scratch-space/ && tar -cvf /workspace/customworkspace/rules_docker-master.tar rules_docker-master'] ``` +### Workspaces + +`workspaces` are a way of declaring volumes you expect to be made available to your +executing `Task` and the path to make them available at. They are similar to +[`volumes`](#volumes) but allow you to enforce at runtime that the volumes have +been attached and [allow you to specify subpaths](taskruns.md#workspaces) in the volumes +to attach. + +The volume will be made available at `/workspace/myworkspace`, or you can override +this with `mountPath`. The value at `mountPath` can be anywhere on your pod's filesystem. +The path will be available via [variable substitution](#variable-substitution) with +`$(workspaces.myworkspace.path)`. + +A task can declare that it will not write to the volume by adding `readOnly: true` +to the workspace declaration. This will in turn mark the volumeMount as `readOnly` +on the Task's underlying pod. + +The actual volumes must be provided at runtime +[in the `TaskRun`](taskruns.md#workspaces). +In a future iteration ([#1438](https://github.com/tektoncd/pipeline/issues/1438)) +it [will be possible to specify these in the `PipelineRun`](pipelineruns.md#workspaces) +as well. + +For example: + +```yaml +spec: + steps: + - name: write-message + image: ubuntu + script: | + #!/usr/bin/env bash + set -xe + echo hello! > $(workspaces.messages.path)/message + workspaces: + - name: messages + description: The folder where we write the message to + mountPath: /custom/path/relative/to/root +``` + +_For a complete example see [workspace.yaml](../examples/v1beta1/taskruns/workspace.yaml)._ + ### Results Specifies one or more result files in which you want the task's [`steps`](#steps) to write a result. All result files are written @@ -365,7 +411,7 @@ into the `/tekton/results` folder. This folder is created automatically if the t For example, this task: ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: print-date @@ -426,48 +472,6 @@ For example, use volumes to accomplish one of the following common tasks: unsafe_. Use [kaniko](https://github.com/GoogleContainerTools/kaniko) instead. This is used only for the purposes of demonstration. -### Workspaces - -`workspaces` are a way of declaring volumes you expect to be made available to your -executing `Task` and the path to make them available at. They are similar to -[`volumes`](#volumes) but allow you to enforce at runtime that the volumes have -been attached and [allow you to specify subpaths](taskruns.md#workspaces) in the volumes -to attach. - -The volume will be made available at `/workspace/myworkspace`, or you can override -this with `mountPath`. The value at `mountPath` can be anywhere on your pod's filesystem. -The path will be available via [variable substitution](#variable-substitution) with -`$(workspaces.myworkspace.path)`. - -A task can declare that it will not write to the volume by adding `readOnly: true` -to the workspace declaration. This will in turn mark the volumeMount as `readOnly` -on the Task's underlying pod. - -The actual volumes must be provided at runtime -[in the `TaskRun`](taskruns.md#workspaces). -In a future iteration ([#1438](https://github.com/tektoncd/pipeline/issues/1438)) -it [will be possible to specify these in the `PipelineRun`](pipelineruns.md#workspaces) -as well. - -For example: - -```yaml -spec: - steps: - - name: write-message - image: ubuntu - script: | - #!/usr/bin/env bash - set -xe - echo hello! > $(workspaces.messages.path)/message - workspaces: - - name: messages - description: The folder where we write the message to - mountPath: /custom/path/relative/to/root -``` - -_For a complete example see [workspace.yaml](../examples/v1beta1/taskruns/workspace.yaml)._ - ### Step Template Specifies a [`Container`](https://kubernetes.io/docs/concepts/containers/) @@ -572,16 +576,16 @@ has been created to track this bug. - [`workspaces`](#variable-substitution-with-workspaces) - [`volumes`](#variable-substitution-with-volumes) -#### Input and Output substitution +#### Parameter and Resource substitution -[`inputs`](#inputs) and [`outputs`](#outputs) attributes can be used in replacements, +[`params`](#parameters) and [`resources`](#resources) attributes can be used in replacements, including [`params`](#params) and [`resources`](./resources.md#variable-substitution). -Input parameters can be referenced in the `Task` spec using the variable substitution syntax below, +Parameters can be referenced in the `Task` spec using the variable substitution syntax below, where `` is the name of the parameter: ```shell -$(inputs.params.) +$(params.) ``` Param values from resources can also be accessed using [variable substitution](./resources.md#variable-substitution) @@ -593,16 +597,15 @@ Referenced parameters of type `array` can be expanded using 'star-expansion' by So, with the following parameter: ```yaml -inputs: - params: - - name: array-param - value: - - "some" - - "array" - - "elements" +params: + - name: array-param + value: + - "some" + - "array" + - "elements" ``` -then `command: ["first", "$(inputs.params.array-param[*])", "last"]` will become +then `command: ["first", "$(params.array-param[*])", "last"]` will become `command: ["first", "some", "array", "elements", "last"]` Note that array parameters __*must*__ be referenced in a completely isolated string within a larger string array. @@ -614,14 +617,14 @@ the string isn't isolated: ```yaml - name: build-step image: gcr.io/cloud-builders/some-image - args: ["build", "additionalArg $(inputs.params.build-args[*])"] + args: ["build", "additionalArg $(params.build-args[*])"] ``` Similarly, referencing `build-args` in a non-array field is also invalid: ```yaml - name: build-step - image: "$(inputs.params.build-args[*])" + image: "$(params.build-args[*])" args: ["build", "args"] ``` @@ -630,7 +633,7 @@ A valid reference to the `build-args` parameter is isolated and in an eligible f ```yaml - name: build-step image: gcr.io/cloud-builders/some-image - args: ["build", "$(inputs.params.build-args[*])", "additonalArg"] + args: ["build", "$(params.build-args[*])", "additonalArg"] ``` #### Variable Substitution with Workspaces @@ -682,36 +685,35 @@ This is used only for the purposes of demonstration. ```yaml spec: - inputs: - resources: + params: + # These may be overridden, but provide sensible defaults. + - name: directory + type: string + description: The directory containing the build context. + default: /workspace + - name: dockerfileName + type: string + description: The name of the Dockerfile + default: Dockerfile + resources: + inputs: - name: workspace type: git - params: - # These may be overridden, but provide sensible defaults. - - name: directory - type: string - description: The directory containing the build context. - default: /workspace - - name: dockerfileName - type: string - description: The name of the Dockerfile - default: Dockerfile - outputs: - resources: + outputs: - name: builtImage type: image steps: - name: dockerfile-build image: gcr.io/cloud-builders/docker - workingDir: "$(inputs.params.directory)" + workingDir: "$(params.directory)" args: [ "build", "--no-cache", "--tag", - "$(outputs.resources.image)", + "$(resources.outputs.image.url)", "--file", - "$(inputs.params.dockerfileName)", + "$(params.dockerfileName)", ".", ] volumeMounts: @@ -720,7 +722,7 @@ spec: - name: dockerfile-push image: gcr.io/cloud-builders/docker - args: ["push", "$(outputs.resources.image)"] + args: ["push", "$(resources.outputs.image.url)"] volumeMounts: - name: docker-socket mountPath: /var/run/docker.sock @@ -765,54 +767,53 @@ spec: ```yaml spec: - inputs: - params: - - name: CFGNAME - type: string - description: Name of config map - - name: volumeName - type: string - description: Name of volume + params: + - name: CFGNAME + type: string + description: Name of config map + - name: volumeName + type: string + description: Name of volume steps: - image: ubuntu script: | #!/usr/bin/env bash cat /var/configmap/test volumeMounts: - - name: "$(inputs.params.volumeName)" + - name: "$(params.volumeName)" mountPath: /var/configmap volumes: - - name: "$(inputs.params.volumeName)" + - name: "$(params.volumeName)" configMap: - name: "$(inputs.params.CFGNAME)" + name: "$(params.CFGNAME)" ``` #### Using secret as environment source ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: goreleaser spec: - inputs: - params: - - name: package - type: string - description: base package to build in - - name: github-token-secret - type: string - description: name of the secret holding the github-token - default: github-token - resources: + params: + - name: package + type: string + description: base package to build in + - name: github-token-secret + type: string + description: name of the secret holding the github-token + default: github-token + resources: + inputs: - name: source type: git - targetPath: src/$(inputs.params.package) + targetPath: src/$(params.package) steps: - name: release image: goreleaser/goreleaser - workingDir: /workspace/src/$(inputs.params.package) + workingDir: /workspace/src/$(params.package) command: - goreleaser args: @@ -823,32 +824,31 @@ spec: - name: GITHUB_TOKEN valueFrom: secretKeyRef: - name: $(inputs.params.github-token-secret) + name: $(params.github-token-secret) key: bot-token ``` #### Using a sidecar ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: with-sidecar-task spec: - inputs: - params: - - name: sidecar-image - type: string - description: Image name of the sidecar container - - name: sidecar-env - type: string - description: Environment variable value + params: + - name: sidecar-image + type: string + description: Image name of the sidecar container + - name: sidecar-env + type: string + description: Environment variable value sidecars: - name: sidecar - image: $(inputs.params.sidecar-image) + image: $(params.sidecar-image) env: - name: SIDECAR_ENV - value: $(inputs.params.sidecar-env) + value: $(params.sidecar-env) steps: - name: test image: hello-world diff --git a/docs/tutorial.md b/docs/tutorial.md index a22c4db6114..fbb9ff10ff1 100644 --- a/docs/tutorial.md +++ b/docs/tutorial.md @@ -19,16 +19,16 @@ specific to a given cloud computing service. Before you begin this tutorial, make sure you have [installed and configured](install.md) the latest release of Tekton on your Kubernetes cluster, including the -[Tekton CLI](https://github.com/tektoncd/cli). +[Tekton CLI](https://github.com/tektoncd/cli). If you would like to complete this tutorial on your local workstation, see [Running this tutorial locally](#running-this-tutorial-locally). To learn more about the Tekton entities involved in this tutorial, see [Further reading](#further-reading). ## Creating and running a `Task` -A [`Task`](tasks.md) defines a series of `steps` that run in a desired order and complete a set amount of build work. Every `Task` runs as a Pod on your Kubernetes cluster with each `step` as its own container. For example, the following `Task` outputs "Hello World": +A [`Task`](tasks.md) defines a series of `steps` that run in a desired order and complete a set amount of build work. Every `Task` runs as a Pod on your Kubernetes cluster with each `step` as its own container. For example, the following `Task` outputs "Hello World": ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: echo-hello-world @@ -44,7 +44,7 @@ spec: To run this `Task`, instantiate it using a [`TaskRun`](taskruns.md): ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: TaskRun metadata: name: echo-hello-world-task-run @@ -148,28 +148,27 @@ introduced earlier. The arguments of the `Task` command support variable substit the `Task` definition is constant and the value of parameters can change during runtime. ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: build-docker-image-from-git-source spec: - inputs: - resources: + params: + - name: pathToDockerFile + type: string + description: The path to the dockerfile to build + default: /workspace/docker-source/Dockerfile + - name: pathToContext + type: string + description: | + The build context used by Kaniko + (https://github.com/GoogleContainerTools/kaniko#kaniko-build-contexts) + default: /workspace/docker-source + resources: + inputs: - name: docker-source type: git - params: - - name: pathToDockerFile - type: string - description: The path to the dockerfile to build - default: /workspace/docker-source/Dockerfile - - name: pathToContext - type: string - description: - The build context used by Kaniko - (https://github.com/GoogleContainerTools/kaniko#kaniko-build-contexts) - default: /workspace/docker-source - outputs: - resources: + outputs: - name: builtImage type: image steps: @@ -182,9 +181,9 @@ spec: command: - /kaniko/executor args: - - --dockerfile=$(inputs.params.pathToDockerFile) - - --destination=$(outputs.resources.builtImage.url) - - --context=$(inputs.params.pathToContext) + - --dockerfile=$(params.pathToDockerFile) + - --destination=$(resources.outputs.builtImage.url) + - --context=$(params.pathToContext) ``` ### Configuring `Task` execution credentials @@ -221,11 +220,11 @@ kubectl apply -f You are now ready for your first `TaskRun`! -A `TaskRun` binds the inputs and outputs to already defined `PipelineResources`, sets values +A `TaskRun` binds the inputs and outputs to already defined `PipelineResources`, sets values for variable substitution parameters, and executes the `Steps` in the `Task`. ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: TaskRun metadata: name: build-docker-image-from-git-source-task-run @@ -233,18 +232,17 @@ spec: serviceAccountName: tutorial-service taskRef: name: build-docker-image-from-git-source - inputs: - resources: + params: + - name: pathToDockerFile + value: Dockerfile + - name: pathToContext + value: /workspace/docker-source/examples/microservices/leeroy-web #configure: may change according to your source + resource: + inputs: - name: docker-source resourceRef: name: skaffold-git - params: - - name: pathToDockerFile - value: Dockerfile - - name: pathToContext - value: /workspace/docker-source/examples/microservices/leeroy-web #configure: may change according to your source - outputs: - resources: + outputs: - name: builtImage resourceRef: name: skaffold-image-leeroy-web @@ -333,7 +331,7 @@ along with the along with corresponding inputs and outputs for each `Task`. You Below is an example definition of a `Pipeline`: ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata: name: tutorial-pipeline @@ -380,25 +378,25 @@ spec: The above `Pipeline` is referencing a `Task` called `deploy-using-kubectl` defined as follows: ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: deploy-using-kubectl spec: - inputs: - resources: + params: + - name: path + type: string + description: Path to the manifest to apply + - name: yamlPathToImage + type: string + description: | + The path to the image to replace in the yaml manifest (arg to yq) + resources: + inputs: - name: source type: git - name: image type: image - params: - - name: path - type: string - description: Path to the manifest to apply - - name: yamlPathToImage - type: string - description: - The path to the image to replace in the yaml manifest (arg to yq) steps: - name: replace-image image: mikefarah/yq @@ -406,16 +404,16 @@ spec: args: - "w" - "-i" - - "$(inputs.params.path)" - - "$(inputs.params.yamlPathToImage)" - - "$(inputs.resources.image.url)" + - "$(params.path)" + - "$(params.yamlPathToImage)" + - "$(resources.inputs.image.url)" - name: run-kubectl image: lachlanevenson/k8s-kubectl command: ["kubectl"] args: - "apply" - "-f" - - "$(inputs.params.path)" + - "$(params.path)" ``` ### Configuring `Pipeline` execution credentials @@ -442,7 +440,7 @@ kubectl create clusterrolebinding tutorial-binding \ To run your `Pipeline`, instantiate it with a [`PipelineRun`](pipelineruns.md) as follows: ```yaml -apiVersion: tekton.dev/v1alpha1 +apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: name: tutorial-pipeline-run-1 @@ -526,7 +524,7 @@ Complete these prerequisites to run this tutorial locally: - Install the [required tools](https://github.com/tektoncd/pipeline/blob/master/DEVELOPMENT.md#requirements). - Install [Docker for Desktop](https://www.docker.com/products/docker-desktop) and configure it to use six CPUs, - 10 GB of RAM and 2GB of swap space. + 10 GB of RAM and 2GB of swap space. - Set `host.docker.local:5000` as an insecure registry with Docker for Desktop. See the [Docker insecure registry documentation](https://docs.docker.com/registry/insecure/). for details. @@ -547,7 +545,7 @@ You must reconfigure any `image` resource definitions in your `PipelineResources - Set the URL to `host.docker.internal:5000/myregistry/` - Set the `KO_DOCKER_REPO` variable to `localhost:5000/myregistry` before using `ko` -- Set your applications (such as deployment definitions) to push to +- Set your applications (such as deployment definitions) to push to `localhost:5000/myregistry/`. ### Reconfigure logging