Allow custom tasks to use workspaces, service accounts, pod templates

[GregDritschler]

Fixes #3593
Fixes #3594

Allow custom tasks to use workspaces, service accounts, and pod templates.
These features will be needed to build more complex custom tasks.

Changes

• Add workspaces, service account name, and pod template to Run spec.
• Update pipelinerun controller to pass workspaces from pipeline task and service account name and pod template from PipelineRun to a Run

/kind feature

Submitter Checklist

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

• Includes tests (if functionality changed/added)
• 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)

See the contribution guide for more details.

Double check this list of stuff that's easy to miss:

• If you are adding a new binary/image to the cmd dir, please update
  the release Task to build and release this image.

Reviewer Notes

If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.

Release Notes

Allow custom tasks to use workspaces, service accounts, and pod templates

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1alpha1/run_validation.go	92.9%	93.8%	0.9
pkg/apis/pipeline/v1beta1/pipeline_validation.go	99.6%	99.6%	-0.0
pkg/reconciler/pipelinerun/pipelinerun.go	82.6%	82.7%	0.1

[imjasonh]

Thanks for adding this! 🎉

(Not necessarily for this PR) What do you think about Tekton providing an error variable that custom task run webhooks and reconcilers can return to indicate that some feature is unsupported for that type of custom task? e.g., ErrWorkspapcesUnsupported or something. This could also make it clearer to custom task implementation authors what they should return when a feature is unsupported.

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1alpha1/run_validation.go	92.9%	93.8%	0.9
pkg/apis/pipeline/v1beta1/pipeline_validation.go	99.6%	99.6%	-0.0
pkg/reconciler/pipelinerun/pipelinerun.go	82.6%	82.7%	0.1

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1alpha1/run_validation.go	92.9%	93.8%	0.9
pkg/apis/pipeline/v1beta1/pipeline_validation.go	99.6%	99.6%	-0.0
pkg/reconciler/pipelinerun/pipelinerun.go	82.6%	82.7%	0.1

[GregDritschler]

Thanks for adding this! 🎉

(Not necessarily for this PR) What do you think about Tekton providing an error variable that custom task run webhooks and reconcilers can return to indicate that some feature is unsupported for that type of custom task? e.g., ErrWorkspapcesUnsupported or something. This could also make it clearer to custom task implementation authors what they should return when a feature is unsupported.

Okay. I added a couple of reasons to run_types.go, RunReasonWorkspaceNotSupported and RunReasonPodTemplateNotSupported. It's unclear whether there should be one for the service account because it will always be there (with the default SA) even if unspecified by the user.

[imjasonh]

Thanks for adding this! 🎉
(Not necessarily for this PR) What do you think about Tekton providing an error variable that custom task run webhooks and reconcilers can return to indicate that some feature is unsupported for that type of custom task? e.g., ErrWorkspapcesUnsupported or something. This could also make it clearer to custom task implementation authors what they should return when a feature is unsupported.

Okay. I added a couple of reasons to run_types.go, RunReasonWorkspaceNotSupported and RunReasonPodTemplateNotSupported. It's unclear whether there should be one for the service account because it will always be there (with the default SA) even if unspecified by the user.

+1, thanks

The reason might be "only the default SA is supported" or more generally "specified SA is invalid", but either way that's something we can add later as needed.

/lgtm

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sbwsg

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 [sbwsg]

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