From 9e237e99f581451f56d76b025d401c0382a38689 Mon Sep 17 00:00:00 2001 From: Christie Wilson Date: Mon, 14 Jan 2019 10:47:31 -0800 Subject: [PATCH] Update docs and examples with new resource bindings Now resources will be bound to a "name" which is used in the `Pipeline` to refer to them. This will simplify the binding declarations in `PipelineRun` and also make the `Pipeline` definition solely responsible for linking resources to Tasks. Toward #320 --- README.md | 4 +- docs/Concepts.md | 74 ++---------- docs/tutorial.md | 143 +++++++++++----------- docs/using.md | 211 ++++++++++++++++++++------------- examples/README.md | 4 +- examples/pipeline.yaml | 41 ++++++- examples/run/pipeline-run.yaml | 43 ++----- 7 files changed, 258 insertions(+), 262 deletions(-) diff --git a/README.md b/README.md index a7e94daf032..d90f75417a7 100644 --- a/README.md +++ b/README.md @@ -26,9 +26,9 @@ Pipelines are **Typed**: ## Want to start using Pipelines? -- Jump in with [the quickstart!](docs/tutorial.md) +- Jump in with [the tutorial!](docs/tutorial.md) - [Learn about the Concepts](/docs/Concepts.md) -- [See how to use it](/docs/using.md) +- [Read about how to use it](/docs/using.md) - Look at [some examples](/examples) ## Want to contribute? diff --git a/docs/Concepts.md b/docs/Concepts.md index 989e29f034c..f13cc0b0ec9 100644 --- a/docs/Concepts.md +++ b/docs/Concepts.md @@ -20,13 +20,10 @@ High level details of this design: triggered by events or by manually creating [PipelineRuns](#pipelinerun) - [Tasks](#task) can exist and be invoked completely independently of [Pipelines](#pipeline); they are highly cohesive and loosely coupled -- Test results are a first class concept, being able to navigate test results - easily is powerful (e.g. see failures easily, dig into logs, e.g. like - [the Jenkins test analyzer plugin](https://wiki.jenkins.io/display/JENKINS/Test+Results+Analyzer+Plugin)) - [Tasks](#task) can depend on artifacts, output and parameters created by other tasks. -- [Resources](#pipelineresources) are the artifacts used as inputs and outputs - of TaskRuns. +- [PipelineResources](#pipelineresources) are the artifacts used as inputs and outputs + of Tasks. ## Building Blocks of Pipeline CRDs @@ -44,11 +41,10 @@ Below diagram lists the main custom resources created by Pipeline CRDs: ### Task -A `Task` is a collection of sequential steps you would want to run as part of -your continuous integration flow. A Task will run inside a container on your -cluster. +A `Task` is a collection of sequential steps you would want to run as part of your +continuous integration flow. A task will run inside a container on your cluster. -A Task declares: +A `Task` declares: - [Inputs](#inputs) - [Outputs](#outputs) @@ -56,49 +52,19 @@ A Task declares: #### Inputs -Inputs declare the inputs the Task needs. Every task input resource should -provide name and type (like git, image). It can also provide optionally -`targetPath` to initialize the resource in specific directory. If `targetPath` -is set then the resource will be initialized under `/workspace/targetPath`. If -`targetPath` is not specified then the resource will be initialized -under`/workspace`. The following example demonstrates how git input repository -could be initialized in `GOPATH` to run tests. - -```yaml -apiVersion: pipeline.knative.dev/v1alpha1 -kind: Task -metadata: - name: task-with-input - namespace: default -spec: - inputs: - resources: - - name: workspace - type: git - targetPath: go/src/github.com/knative/build-pipeline - steps: - - name: unit-tests - image: golang - command: ["go"] - args: - - "test" - - "./..." - workingDir: "/workspace/go/src/github.com/knative/build-pipeline" - env: - - name: GOPATH - value: /workspace/go -``` +Declare the inputs the `Task` needs. Every `Task` input resource should provide name +and type (like git, image). #### Outputs -Outputs declare the outputs task will produce. +Outputs declare the outputs `Task` will produce. #### Steps Steps is a sequence of steps to execute. Each step is [a container image](./using.md#image-contract). -Here is an example simple Task definition which echoes "hello world". The +Here is an example simple `Task` definition which echoes "hello world". The `hello-world` task does not define any inputs or outputs. It only has one step named `echo`. The step uses the builder image `busybox` @@ -122,21 +88,7 @@ spec: Examples of `Task` definitions with inputs and outputs are [here](../examples) -##### Step Entrypoint - -To get the logs out of a [`Task`](#task), Knative provides its own executable -that wraps the `command` and `args` values specified in the `steps`. This means -that every `Task` must use `command`, and cannot rely on the image's -`entrypoint`. - -##### Configure Entrypoint image - -To run a step needs to pull an `Entrypoint` image. Knative provides a way for -you to configure the `Entrypoint` image in case it is hard to pull in your -environment. To do that you can edit the `image`'s value in a configmap named -[`config-entrypoint`](./../config/config-entrypoint.yaml). - -#### ClusterTask +#### Cluster Task A `ClusterTask` is similar to `Task` but with a cluster-wide scope. Cluster Tasks are available in all namespaces, typically used to conveniently provide @@ -171,7 +123,7 @@ spec: name: hello-world ``` -Examples of pipelines with more complex DAGs are [here](../examples/) +Examples of more complex `Pipelines` are [in our examples dir](../examples/). #### PipelineResources @@ -185,10 +137,10 @@ For example: deployed in a cluster. - A Task's output can be a jar file to be uploaded to a storage bucket. -Read more on `PipelineResources` and their types [here](./using.md) +Read more on PipelineResources and their types [here](./using.md#creating-pipelineresources). `PipelineResources` in a Pipeline are the set of objects that are going to be -used as inputs and outputs of a `TaskRun`. +used as inputs and outputs of a `Task`. #### Runs diff --git a/docs/tutorial.md b/docs/tutorial.md index 642e859bd95..5edb9a249e9 100644 --- a/docs/tutorial.md +++ b/docs/tutorial.md @@ -1,13 +1,24 @@ -# Hello World Task +# Hello World Tutorial + +Welcome to the Pipeline tutorial! + +This tutorial will walk you through creating and running some simple +[`Tasks`](concepts.md#task), [`Pipelines`](concepts.md#pipeline) and running them +by creating [`TaskRuns`](concepts.md#taskruns) and [`PipelineRuns`](concepts.md#pipelineruns). + +* [Creating a hello world `Task`](#tasks) +* [Creating a hello world `Pipeline`](#pipelines) + +For more details on using `Pipelines`, see [our usage docs](usage.md). + +## Tasks The main objective of the Pipeline CRDs is to run your Task individually or as a part of a Pipeline. Every task runs as a Pod on your Kubernetes cluster with each step as its own container. -## Tasks - -A `Task` defines the work that needs to be executed, for example the following -is a simple task that will echo hello world, +A [`Task`](concepts.md#task) defines the work that needs to be executed, for +example the following is a simple task that will echo hello world: ```yaml apiVersion: pipeline.knative.dev/v1alpha1 @@ -26,8 +37,8 @@ spec: The `steps` are a series of commands to be sequentially executed by the task. -A `TaskRun` runs the `task` you defined. Here is a simple example of a `TaskRun` -you can use to execute your task: +A [`TaskRun`](concepts.md#taskruns) runs the `Task` you defined. Here is a +simple example of a `TaskRun` you can use to execute your task: ```yaml apiVersion: pipeline.knative.dev/v1alpha1 @@ -59,9 +70,6 @@ You will get an output similar to the following: apiVersion: pipeline.knative.dev/v1alpha1 kind: TaskRun metadata: - annotations: - kubectl.kubernetes.io/last-applied-configuration: | - {"apiVersion":"pipeline.knative.dev/v1alpha1","kind":"TaskRun","metadata":{"annotations":{},"name":"echo-hello-world-task-run","namespace":"default"},"spec":{"taskRef":{"name":"echo-hello-world"},"trigger":{"type":"manual"}}} creationTimestamp: 2018-12-11T15:49:13Z generation: 1 name: echo-hello-world-task-run @@ -104,17 +112,18 @@ status: The status of type `Succeeded = True` shows the task ran successfully. -# Task Inputs and Outputs +### Task Inputs and Outputs In more common scenarios, a Task needs multiple steps with input and output resources to process. For example a Task could fetch source code from a GitHub repository and build a Docker image from it. -`PipelinesResources` are used to define the artifacts that can be passed in and -out of a task. There are a few system defined resource types ready to use, and -the following are two examples of the resources commonly needed. +[`PipelinesResources`](concepts.md#pipelineresources) are used to define the +artifacts that can be passed in and out of a task. There are a few system +defined resource types ready to use, and the following are two examples of +the resources commonly needed. -`git` resource represents a git repository with a specific revision: +The [`git` resource](using.md#git-resource) represents a git repository with a specific revision: ```yaml apiVersion: pipeline.knative.dev/v1alpha1 @@ -130,7 +139,7 @@ spec: value: https://github.com/GoogleContainerTools/skaffold ``` -and the `image` resource represents the Docker image to be built by the task: +The [`image` resource](using.md#image-resource) represents theimage to be built by the task: ```yaml apiVersion: pipeline.knative.dev/v1alpha1 @@ -144,9 +153,9 @@ spec: value: gcr.io//leeroy-web ``` -The following is a Task with inputs and outputs. The input resource is a GitHub -repository and the output is the Docker image produced from that source. The -args of the Task command support templating so that the definition of Task is +The following is a `Task` with inputs and outputs. The input resource is a GitHub +repository and the output is the image produced from that source. The +args of the task command support templating so that the definition of task is constant and the value of parameters can change in runtime. ```yaml @@ -254,9 +263,6 @@ You will get an output similar to the following: apiVersion: pipeline.knative.dev/v1alpha1 kind: TaskRun metadata: - annotations: - kubectl.kubernetes.io/last-applied-configuration: | - {"apiVersion":"pipeline.knative.dev/v1alpha1","kind":"TaskRun","metadata":{"annotations":{},"name":"build-docker-image-from-git-source-task-run","namespace":"default"},"spec":{"inputs":{"params":[{"name":"pathToDockerFile","value":"Dockerfile"},{"name":"pathToContext","value":"/workspace/examples/microservices/leeroy-web"}],"resources":[{"name":"workspace","resourceRef":{"name":"skaffold-git"}}]},"outputs":{"resources":[{"name":"builtImage","resourceRef":{"name":"skaffold-image-leeroy-web"}}]},"results":{"type":"gcs","url":"gcs://somebucket/results/logs"},"taskRef":{"name":"build-docker-image-from-git-source"},"trigger":{"type":"manual"}}} creationTimestamp: 2018-12-11T18:14:29Z generation: 1 name: build-docker-image-from-git-source-task-run @@ -321,10 +327,12 @@ resource definition. # Pipeline -Pipeline defines a graph of tasks to execute in a specific order, while also -indicating if any outputs should be used as inputs of a following Task by using -the `providedBy` field. The same templating you used in tasks is also available -in pipeline: +A [`Pipeline`](concepts.md#pipelines) defines a list of tasks to execute in +order, while also indicating if any outputs should be used as inputs +of a following task by using [the `providedBy` field](using.md#providedby). +The same templating you used in tasks is also available in pipeline. + +For example: ```yaml apiVersion: pipeline.knative.dev/v1alpha1 @@ -332,6 +340,11 @@ kind: Pipeline metadata: name: tutorial-pipeline spec: + resources: + - name: source-repo + type: git + - name: web-image + type: image tasks: - name: build-skaffold-web taskRef: @@ -341,13 +354,24 @@ spec: value: Dockerfile - name: pathToContext value: /workspace/examples/microservices/leeroy-web + resources: + inputs: + - name: workspace + resource: source-repo + outputs: + - name: image + resource: web-image - name: deploy-web taskRef: name: demo-deploy-kubectl resources: + inputs: + - name: workspace + resource: source-repo - name: image + resource: web-image providedBy: - - build-skaffold-web + - build-skaffold-web params: - name: path value: /workspace/examples/microservices/leeroy-web/kubernetes/deployment.yaml @@ -357,8 +381,8 @@ spec: value: "spec.template.spec.containers[0].image" ``` -The above Pipeline is referencing a task to `deploy-using-kubectl` which can be -found here: +The above `Pipeline` is referencing a `Task` called `deploy-using-kubectl` which can be found +here: ```yaml apiVersion: pipeline.knative.dev/v1alpha1 @@ -402,7 +426,7 @@ spec: - "${inputs.params.path}" ``` -To run the Pipeline, create a PipelineRun as follows: +To run the `Pipeline`, create a [`PipelineRun`](concepts.md#pipelinerun) as follows: ```yaml apiVersion: pipeline.knative.dev/v1alpha1 @@ -415,26 +439,15 @@ spec: trigger: type: manual resources: - - name: build-skaffold-web - inputs: - - name: workspace - resourceRef: - name: skaffold-git - outputs: - - name: builtImage - resourceRef: - name: skaffold-image-leeroy-web - - name: deploy-web - inputs: - - name: workspace - resourceRef: - name: skaffold-git - - name: image - resourceRef: - name: skaffold-image-leeroy-web + - name: source-repo + resourceRef: + name: skaffold-git + - name: web-image + resourceRef: + name: skaffold-image-leeroy-web ``` -The PipelineRun will create the TaskRuns corresponding to each Task and collect +The `PipelineRun` will create the `TaskRuns` corresponding to each `Task` and collect the results. To apply the yaml files use the following command, you will need to apply the @@ -444,7 +457,7 @@ To apply the yaml files use the following command, you will need to apply the kubectl apply -f ``` -To see the output of the PipelineRun, use the following command: +To see the output of the `PipelineRun`, use the following command: ```bash kubectl get pipelineruns/tutorial-pipeline-run-1 -o yaml @@ -457,8 +470,6 @@ apiVersion: pipeline.knative.dev/v1alpha1 kind: PipelineRun metadata: annotations: - kubectl.kubernetes.io/last-applied-configuration: | - {"apiVersion":"pipeline.knative.dev/v1alpha1","kind":"PipelineRun","metadata":{"annotations":{},"name":"tutorial-pipeline-run-1","namespace":"default"},"spec":{"pipelineRef":{"name":"tutorial-pipeline"},"resources":[{"inputs":[{"name":"workspace","resourceRef":{"name":"skaffold-git"}}],"name":"build-skaffold-web","outputs":[{"name":"builtImage","resourceRef":{"name":"skaffold-image-leeroy-web"}}]},{"inputs":[{"name":"workspace","resourceRef":{"name":"skaffold-git"}},{"name":"image","resourceRef":{"name":"skaffold-image-leeroy-web"}}],"name":"deploy-web"}],"trigger":{"type":"manual"}}} creationTimestamp: 2018-12-11T20:30:19Z generation: 1 name: tutorial-pipeline-run-1 @@ -471,28 +482,14 @@ spec: pipelineRef: name: tutorial-pipeline resources: - - inputs: - - name: workspace - paths: null - resourceRef: - name: skaffold-git - name: build-skaffold-web - outputs: - - name: builtImage - paths: null - resourceRef: - name: skaffold-image-leeroy-web - - inputs: - - name: workspace - paths: null - resourceRef: - name: skaffold-git - - name: image - paths: null - resourceRef: - name: skaffold-image-leeroy-web - name: deploy-web - outputs: null + - name: source-repo + paths: null + resourceRef: + name: skaffold-git + - name: web-image + paths: null + resourceRef: + name: skaffold-image-leeroy-web serviceAccount: "" trigger: type: manual diff --git a/docs/using.md b/docs/using.md index f7b4e10ffb0..1307fa2886e 100644 --- a/docs/using.md +++ b/docs/using.md @@ -15,85 +15,93 @@ [Kaniko](https://github.com/GoogleContainerTools/kaniko)) and others will be specific to your project (e.g. running your particular set of unit tests). 2. Create a `Pipeline` which expresses the Tasks you would like to run and what - [Resources](#creating-resources) the Tasks need. Use - [`providedBy`](#providedBy) to express the order the `Tasks` should run in. + [PipelineResources](#resources-in-a-pipeline) the Tasks need. Use + [`providedBy`](#providedBy) to express when the input of a `Task` should come + from the output of a previous `Task`. See [the example Pipeline](../examples/pipeline.yaml). +### PipelineResources in a Pipeline + +In order for a `Pipeline` to execute, it will probably need +[`PipelineResources`](#creating-pipelineresources) which will be provided to +`Tasks` as inputs and outputs. + +Your `Pipeline` must declare the `PipelineResources` it needs in a `resources` +section in the `spec`, giving each a name which will be used to refer to these +`PipelineResources` in the `Tasks`. + +For example: + +```yaml +spec: + resources: + - name: my-repo + type: git + - name: my-image + type: image +``` + +These `PipelineResources` can then be provided to `Task`s in the `Pipeline` as +inputs and outputs, for example: + +```yaml +spec: + #... + tasks: + - name: build-the-image + taskRef: + name: build-push + resources: + inputs: + - name: workspace + resource: my-repo + outputs: + - name: image + resource: my-image +``` + ### ProvidedBy -When you need to execute `Tasks` in a particular order, it will likely be -because they are operating over the same `Resources` (e.g. your unit test Task -must run first against your git repo, then you build an image from that repo, -then you run integration tests against that image). +Sometimes you will have `Tasks` that need to take as input the output of a previous +`Task`, for example, an image built by a previous `Task`. -We express this ordering by adding `providedBy` on `Resources` that our `Tasks` +We express this dependency by adding `providedBy` on `Resources` that our `Tasks` need. - The (optional) `providedBy` key on an `input source` defines a set of previous - Task names. -- When the `providedBy` key is specified on an input source, only the version of - the resource that is provided by the defined list of tasks is used. -- The `providedBy` allows for `Task`s to fan in and fan out, and ordering can be - expressed explicitly using this key since a Task needing a resource from a - another Task would have to run after. -- The name used in the `providedBy` is the name of `PipelineTask`. + `PipelineTasks` (i.e. the named instance of a `Task`) in the `Pipeline` +- When the `providedBy` key is specified on an input source, the version of + the resource that is provided by the defined list of tasks is used +- The `providedBy` can support fan in and fan out - The name of the `PipelineResource` must correspond to a `PipelineResource` from the `Task` that the referenced `PipelineTask` provides as an output For example see this `Pipeline` spec: ```yaml -- name: build-skaffold-app +- name: build-app taskRef: name: build-push - params: - - name: pathToDockerFile - value: Dockerfile - - name: pathToContext - value: /workspace/examples/microservices/leeroy-app + resources: + outputs: + - name: image + resource: my-image - name: deploy-app taskRef: - name: demo-deploy-kubectl + name: deploy-kubectl resources: - - name: image - providedBy: - - build-skaffold-app -``` - -The `image` resource is expected to be provided to the `deploy-app` `Task` from -the `build-skaffold-app` `Task`. This means that the `PipelineResource` bound to -the `image` input for `deploy-app` must be bound to the same `PipelineResource` -as an output from `build-skaffold-app`. - -This is the corresponding `PipelineRun` spec: - -```yaml - - name: build-skaffold-app - ... - outputs: - - name: builtImage - resourceRef: - name: skaffold-image-leeroy-app - - name: deploy-app - ... inputs: - - name: image - resourceRef: - name: skaffold-image-leeroy-app + - name: my-image + providedBy: + - build-app ``` -You can see that the `builtImage` output from `build-skaffold-app` is bound to -the `skaffold-image-leeroy-app` `PipelineResource`, and the same -`PipelineResource` is bound to `image` for `deploy-app`. +The `my-image` resource is expected to be provided to the `deploy-app` `Task` from +the `build-app` `Task`. This means that the `PipelineResource` `my-image` must also +be declared as an output of `build-app`. -This controls two things: - -1. The order the `Task`s are executed in: `deploy-app` must come after - `build-skaffold-app` -2. The state of the `PipelineResources`: the image provided to `deploy-app` may - be changed by `build-skaffold-app` (WIP, see - [#216](https://github.com/knative/build-pipeline/issues/216)) +For implementation details, see [the developer docs](docs/developers/README.md). ## Creating a Task @@ -112,7 +120,9 @@ To create a Task, you must: Each container image used as a step in a [`Task`](#task) must comply with a specific contract. -When containers are run in a `Task`, the `entrypoint` of the container is +#### Entrypoint + +When containers are run in a `Task`, the `entrypoint` of the container will be overwritten with a custom binary that redirects the logs to a separate location for aggregating the log output. As such, it is always recommended to explicitly specify a command. @@ -164,12 +174,19 @@ steps: value: "world" ``` -### Resource shared between tasks +##### Configure Entrypoint image + +To run a step needs to pull an `Entrypoint` image. Maybe the image is hard to +pull in your environment, so we provide a way for you to configure that by edit +the `image`'s value in a configmap named +[`config-entrypoint`](./../config/config-entrypoint.yaml). + +### Resource sharing between tasks Pipeline Tasks are allowed to pass resources from previous tasks via -`providedBy` field. This feature is implemented using Persistent Volume Claim -under the hood but however has an implication that tasks cannot have any volume -mounted under path `/pvc`. +[`providedBy`](#providedby) field. This feature is implemented using +Persistent Volume Claims under the hood but however has an implication +that tasks cannot have any volume mounted under path `/pvc`. ### Outputs @@ -201,7 +218,7 @@ destination path of input resource is used instead of In the following example Task `tar-artifact` resource is used both as input and output so input resource is downloaded into directory `customworkspace`(as -specified in `targetPath`). Step `untar` extracts tar file into +specified in [`targetPath`](#targetpath)). Step `untar` extracts tar file into `tar-scratch-space` directory , `edit-tar` adds a new file and last step `tar-it-up` creates new tar file and places in `/workspace/customworkspace/` directory. After execution of the Task steps, (new) tar file in directory @@ -230,6 +247,39 @@ steps: args: ['-c', 'cd /workspace/tar-scratch-space/ && tar -cvf /workspace/customworkspace/rules_docker-master.tar rules_docker-master'] ``` +#### targetPath + +Tasks can opitionally provide `targetPath` to initialize resource in specific +directory. If `targetPath` is set then resource will be initialized under +`/workspace/targetPath`. If `targetPath` is not specified then resource will +be initialized under `/workspace`. Following example demonstrates how git input +repository could be initialized in `$GOPATH` to run tests: + +```yaml +apiVersion: pipeline.knative.dev/v1alpha1 +kind: Task +metadata: + name: task-with-input + namespace: default +spec: + inputs: + resources: + - name: workspace + type: git + targetPath: go/src/github.com/knative/build-pipeline + steps: + - name: unit-tests + image: golang + command: ["go"] + args: + - "test" + - "./..." + workingDir: "/workspace/go/src/github.com/knative/build-pipeline" + env: + - name: GOPATH + value: /workspace/go +``` + ### Conventions - `/workspace/`: @@ -286,8 +336,8 @@ In order to run a Pipeline, you will need to provide: 1. A Pipeline to run (see [creating a Pipeline](#creating-a-pipeline)) 2. The `PipelineResources` to use with this Pipeline. -On its own, a `Pipeline` declares what `Tasks` to run, and what order to run -them in (implied by [`providedBy`](#providedby)). When running a `Pipeline`, you +On its own, a `Pipeline` declares what `Tasks` to run, and dependencies between +`Task` inputs and outputs via [`providedBy`](#providedby). When running a `Pipeline`, you will need to specify the `PipelineResources` to use with it. One `Pipeline` may need to be run with different `PipelineResources` in cases such as: @@ -298,30 +348,23 @@ need to be run with different `PipelineResources` in cases such as: registry (via the image `PipelineResource`) and Kubernetes cluster (via the cluster `PipelineResource`). -Specify the `PipelineResources` in the PipelineRun using the `resources` -section, for example: +Specify the `PipelineResources` in the PipelineRun using the `resources` section +in the `PipelineRun` spec, for example: ```yaml -resources: - - name: push-kritis - inputs: - - key: workspace - resourceRef: - name: kritis-resources-git - outputs: - - key: builtImage - resourceRef: - name: kritis-resources-image +spec: + resources: + - name: source-repo + resourceRef: + name: skaffold-git + - name: web-image + resourceRef: + name: skaffold-image-leeroy-web + - name: app-image + resourceRef: + name: skaffold-image-leeroy-app ``` -This example section says: - -- For the `Task` in the `Pipeline` called `push-kritis` -- For the input called `workspace`, use the existing resource called - `kritis-resources-git` -- For the output called `builtImage`, use the existing resource called - `kritis-resources-image` - Creation of a `PipelineRun` will trigger the creation of [`TaskRuns`](#running-a-task) for each `Task` in your pipeline. @@ -443,7 +486,7 @@ secrets: - name: test-git-ssh ``` -## Creating Resources +## Creating PipelineResources The following `PipelineResources` are currently supported: diff --git a/examples/README.md b/examples/README.md index 5bfcae9ddb0..1a8c1df2f70 100644 --- a/examples/README.md +++ b/examples/README.md @@ -28,8 +28,8 @@ kubectl apply -f examples/run/output-pipeline-run.yaml from [the Skaffold repo](https://github.com/GoogleContainerTools/skaffold) and deploys them to the repo currently running the Pipeline CRD. -It does this using the `Deployment` in the existing yaml files, so at the moment -there is no guarantee that the image that are built and pushed are the ones that +It does this using the k8s `Deployment` in the skaffold repos's existing yaml files, +so at the moment there is no guarantee that the image that are built and pushed are the ones that are deployed (that would require using the digest of the built image, see https://github.com/knative/build-pipeline/issues/216). diff --git a/examples/pipeline.yaml b/examples/pipeline.yaml index f98d2aff4ed..a0bd0d1fc1b 100644 --- a/examples/pipeline.yaml +++ b/examples/pipeline.yaml @@ -3,6 +3,13 @@ kind: Pipeline metadata: name: demo-pipeline spec: + resources: + - name: source-repo + type: git + - name: web-image + type: image + - name: app-image + type: image tasks: - name: build-skaffold-web taskRef: @@ -12,6 +19,13 @@ spec: value: Dockerfile - name: pathToContext value: /workspace/examples/microservices/leeroy-web + resources: + inputs: + - name: workspace + resource: source-repo + outputs: + - name: image + resource: web-image - name: build-skaffold-app taskRef: name: build-push @@ -20,13 +34,24 @@ spec: value: Dockerfile - name: pathToContext value: /workspace/examples/microservices/leeroy-app + resources: + inputs: + - name: workspace + resource: source-repo + outputs: + - name: image + resource: app-image - name: deploy-app taskRef: name: demo-deploy-kubectl resources: - - name: image - providedBy: - - build-skaffold-app + inputs: + - name: workspace + resource: source-repo + - name: image + resource: app-image + providedBy: + - build-skaffold-app params: - name: path value: /workspace/examples/microservices/leeroy-app/kubernetes/deployment.yaml @@ -38,9 +63,13 @@ spec: taskRef: name: demo-deploy-kubectl resources: - - name: image - providedBy: - - build-skaffold-web + inputs: + - name: workspace + resource: source-repo + - name: image + resource: web-image + providedBy: + - build-skaffold-web params: - name: path value: /workspace/examples/microservices/leeroy-web/kubernetes/deployment.yaml diff --git a/examples/run/pipeline-run.yaml b/examples/run/pipeline-run.yaml index e7a83a16ef2..229a21b2bb9 100644 --- a/examples/run/pipeline-run.yaml +++ b/examples/run/pipeline-run.yaml @@ -12,37 +12,12 @@ spec: type: 'gcs' url: 'gcs://somebucket/results/logs' resources: - - name: build-skaffold-web - inputs: - - name: workspace - resourceRef: - name: skaffold-git - outputs: - - name: builtImage - resourceRef: - name: skaffold-image-leeroy-web - - name: build-skaffold-app - inputs: - - name: workspace - resourceRef: - name: skaffold-git - outputs: - - name: builtImage - resourceRef: - name: skaffold-image-leeroy-app - - name: deploy-app - inputs: - - name: workspace - resourceRef: - name: skaffold-git - - name: image - resourceRef: - name: skaffold-image-leeroy-app - - name: deploy-web - inputs: - - name: workspace - resourceRef: - name: skaffold-git - - name: image - resourceRef: - name: skaffold-image-leeroy-web + - name: source-repo + resourceRef: + name: skaffold-git + - name: web-image + resourceRef: + name: skaffold-image-leeroy-web + - name: app-image + resourceRef: + name: skaffold-image-leeroy-app \ No newline at end of file