WIP Set podTemplate on Tasks to enable multi-arch builds with Matrix

[dorzel]

Changes

Hello! @jeffdyoung and I are working towards implementing the feature requested in: #6742, namely enabling Tekton to do builds on clusters with nodes of multiple architectures by enabling podTemplate to be set on Tasks.

This currently is an extremely basic approach without any of the supporting tests, validation, and other related code changes in order to show a proof of concept and get some feedback on the general approach before creating a TEP. This will of course later also be cleaned up to follow https://github.com/tektoncd/pipeline/blob/main/CONTRIBUTING.md.

These minimal changes do currently work to accomplish the goal, with an example Pipeline like:

kind: PipelineRun
metadata:
  generateName: matrixed-pipelinerun-
spec:
  pipelineSpec:
    tasks:
      - name: build-and-push-manifest
        matrix:
          params:
          - name: arch
            value: 
              - "amd64"
              - "arm64"
        taskSpec:
          results:
            - name: manifest
              type: string
          params:
            - name: arch
          podTemplate:
            nodeSelector:
              kubernetes.io/arch: $(params.arch)
          steps:
            - name: build-and-push
              image: ubuntu
              script: |
                echo "building on $(params.arch)"
                echo "testmanifest-$(params.arch)" | tee $(results.manifest.path)
      - name: create-manifest-list
        params:
          - name: manifest
            value: $(tasks.build-and-push-manifest.results.manifest[*])
        taskSpec:
          steps:
            - name: echo-manifests
              image: ubuntu
              args: ["$(params.manifest[*])"]
              script: echo "$@"

Feedback appreciated, thanks!

Fixes #6742

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
• Has Tests included if any functionality added or changed
• pre-commit Passed
• Follows the commit message standard
• Meets the Tekton contributor standards (including functionality, content, code)
• Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
• Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of good release notes.
• Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

NONE

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: dorzel / name: Dylan Orzel (81ca27d, a9b05dc)

[tekton-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign pritidesai after the PR has been reviewed.
You can assign the PR to them by writing /assign @pritidesai in a comment when ready.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[afrittoli]

/kind feature

[tekton-robot]

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

File	Old Coverage	New Coverage	Delta
pkg/pod/pod.go	93.3%	92.9%	-0.3
pkg/reconciler/taskrun/resources/apply.go	99.4%	98.7%	-0.6

[jeffdyoung]

cc: @aleskandro @Prashanth684 @arewm @adambkaplan

[waveywaves]

/assign

[waveywaves]

@dorzel thank you for opening the draft PR, not sure if a TEP is required as the issue #6742 mentioned doesn't mention a requirement for one. But I will defer to the rest of the team for views on this.

[waveywaves]

Can you add an example to the examples directory? They act as e2e tests as well and help validate if the given code is working properly.

[dorzel]

Certainly!

[chmouel]

I don't know the code very well there, but that only applies to the NodeSelector in the pod template; would there be more podtemplate specs that would needs to be applied here?

[dorzel]

@chmouel Thanks for taking a look - yes I think it would make sense to support variable expansion in all of the podTemplate fields. Currently working on that and will push it up (hopefully) soon with some other updates.

[dorzel]

A note here, I think this will ideally instead be a merge function that overrides only those values that the TaskRun defines instead of the whole podTemplate being replaced, but wanted to get others thoughts on this.