Add a short example of using optional workspaces in when expressions

[ghost]

We've just added support for optional workspaces but I forgot to include
an example showing how to use them as part of a When Expression.

This commit adds a PipelineRun example YAML showing use of a
workspaces.<name>.bound variable in a when expression.

I've also added a line to the pipelines.md file mentioning that you
can use a when expression to evaluate whether an optional workspace was
bound or not.

Changes

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• Includes docs (if user facing)
• Commit messages follow commit message best practices
• Release notes block has been filled in or deleted (only if no user facing changes)

Release Notes

Added a short example of using optional workspaces in when expressions.

[ghost]

/kind documentation

[jerop]

the example looks great, just some suggestions on the docs

[jerop]

I think we should add more detail that the workspace variable is available, in addition to Parameters and Results, in this part of the docs:

pipeline/docs/pipelines.md

Lines 324 to 331 in 0b85cea

	The components of `WhenExpressions` are `Input`, `Operator` and `Values`:
	- `Input` is the input for the `WhenExpression` which can be static inputs or variables ([`Parameters`](#specifying-parameters) or [`Results`](#using-results)). If the `Input` is not provided, it defaults to an empty string.
	- `Operator` represents an `Input`'s relationship to a set of `Values`. A valid `Operator` must be provided, which can be either `in` or `notin`.
	- `Values` is an array of string values. The `Values` array must be provided and be non-empty. It can contain static values or variables ([`Parameters`](#specifying-parameters) or [`Results`](#using-results)).
	The [`Parameters`](#specifying-parameters) are read from the `Pipeline` and [`Results`](#using-results) are read directly from previous [`Tasks`](#adding-tasks-to-the-pipeline). Using [`Results`](#using-results) in a `WhenExpression` in a guarded `Task` introduces a resource dependency on the previous `Task` that produced the `Result`.
	The declared `WhenExpressions` are evaluated before the `Task` is run. If all the `WhenExpressions` evaluate to `True`, the `Task` is run. If any of the `WhenExpressions` evaluate to `False`, the `Task` is not run and the `Task` is listed in the [`Skipped Tasks` section of the `PipelineRunStatus`](pipelineruns.md#monitoring-execution-status).

And include a snippet and reference the end-to-end example here:

pipeline/docs/pipelines.md

Lines 333 to 355 in 0b85cea

	In these examples, `first-create-file` task will only be executed if the `path` parameter is `README.md` and `echo-file-exists` task will only be executed if the `exists` result from `check-file` task is `yes`.
	```yaml
	tasks:
	- name: first-create-file
	when:
	- input: "$(params.path)"
	operator: in
	values: ["README.md"]
	taskRef:
	name: first-create-file
	---
	tasks:
	- name: echo-file-exists
	when:
	- input: "$(tasks.check-file.results.exists)"
	operator: in
	values: ["yes"]
	taskRef:
	name: echo-file-exists
	```
	For an end-to-end example, see [PipelineRun with WhenExpressions](../examples/v1beta1/pipelineruns/pipelinerun-with-when-expressions.yaml).

[ghost]

Nice thank you, I've updated the doc per your suggestions.

[jerop]

/lgtm

[pritidesai]

Looks great, thanks @sbwsg

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: pritidesai

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [pritidesai]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[pritidesai]

Not sure how configmap is handled in our CI.

kubectl apply followed by kubectl delete can not be used with generateName. With kubectl create and generateName, pipelineRun is assigned random name which can be deleted using kubectl delete pr or tkn pr delete but leaves the configmap as is. Does our cleanup cron job, deletes such config maps? Does this concern even apply in our CI?

[ghost]

hm, it looks like we deploy them using ko apply all into the same namespace and cluster.

ko apply in library.sh: https://github.com/tektoncd/plumbing/blob/ef09ae0cb20c1b320b5e3f7a8707030a50d8be17/scripts/library.sh#L472-L480

i believe we run yaml suite in a brand new cluster though. so the configmap is created and then quickly deleted when the cluster is cleaned up.