feat(pipelineloop) : Support latest tektoncd pipeline version.

[ScrapCodes]

Which issue is resolved by this Pull Request:
Resolves #

Description of your changes:
Updated to latest tektoncd version.
go mod tidy
and passed all tests.
Environment tested:

• Python Version (use python --version):
• Tekton Version (use tkn version):
• Kubernetes Version (use kubectl version):
• OS (e.g. from /etc/os-release):

Checklist:

• The title for your pull request (PR) should follow our title convention. Learn more about the pull request title convention used in this repository.

• Do you want this pull request (PR) cherry-picked into the current release branch?

  Learn more about cherry-picking updates into the release branch.

[ScrapCodes]

tested with the included examples i.e. ls examples/*taskspec.yaml

[ScrapCodes]

cc @Tomcli

[Tomcli]

thanks @ScrapCodes, can you update the readme saying that to use the taskSpec example, they will have to deploy master branch Tekton or upcoming Tekton v0.25? Thanks.

/cc @pugangxa @jinchihe we are updating the pipelineloop reconcile logic to handle the new custom task spec from tektoncd/pipeline#3901
Let us know if you see any issue in this PR. Thanks.

[pugangxa]

Thanks @ScrapCodes @Tomcli , Great to saw the PR for tekton merged. Took a look at the PR and generally it's fine. Just some questions:

• Does that mean we do not need PR feature(backend): Allow KFP apiserver to create recursion pipelineLoop CRs for the users #512 ?
• So later we want this embed method to be the standard method right? Then I think we need some DSL side changes to support it.
• When the parent pipelinerun is deleted, the embeded custom resource will be delete right?

[ScrapCodes]

When the parent pipelinerun is deleted, the embeded custom resource will be delete right?

Embedded custom resource is not created in etcd at any point in time.

[Tomcli]

Thanks @ScrapCodes @Tomcli , Great to saw the PR for tekton merged. Took a look at the PR and generally it's fine. Just some questions:

• Does that mean we do not need PR feature(backend): Allow KFP apiserver to create recursion pipelineLoop CRs for the users #512 ?

#512 is only for custom resources that need self reference. E.g. pipeline loops for recursion only

• So later we want this embed method to be the standard method right? Then I think we need some DSL side changes to support it.

Yes, we will need to update the API and SDK to support this new syntax later on. Our goal is to have them based on the Tekton v0.25 release, but we will have some experimental code using the Tekton master branch as the meantime.

• When the parent pipelinerun is deleted, the embeded custom resource will be delete right?

As @ScrapCodes mentioned, the new embedded custom task won't be a separate pipelineloop CR because the pipelineloop controller can get the pipelineloop spec from Tekton Run.

Here is the high level diagram, we are not introducing the validation webhook on the embedded spec yet.

[pugangxa]

Thanks @ScrapCodes @Tomcli , Great to saw the PR for tekton merged. Took a look at the PR and generally it's fine. Just some questions:

• Does that mean we do not need PR feature(backend): Allow KFP apiserver to create recursion pipelineLoop CRs for the users #512 ?

#512 is only for custom resources that need self reference. E.g. pipeline loops for recursion only

Yeah, it's reasonable to do it only for recursion.

• So later we want this embed method to be the standard method right? Then I think we need some DSL side changes to support it.

Yes, we will need to update the API and SDK to support this new syntax later on. Our goal is to have them based on the Tekton v0.25 release, but we will have some experimental code using the Tekton master branch as the meantime.

Got it. So I think we can make it a standard way but still need generate new CR for recursion, but yes the logic can all be done in DSL which is more friendly to users.

• When the parent pipelinerun is deleted, the embeded custom resource will be delete right?

As @ScrapCodes mentioned, the new embedded custom task won't be a separate pipelineloop CR because the pipelineloop controller can get the pipelineloop spec from Tekton Run.

Here is the high level diagram, we are not introducing the validation webhook on the embedded spec yet.

Thanks for the information, from the diagram user will get the response once the pipelinerun created successfully no matter the Run CR creation status? I think we need enhance it later.

[Tomcli]

Thanks for the information, from the diagram user will get the response once the pipelinerun created successfully no matter the Run CR creation status? I think we need enhance it later.

@pugangxa Yes right now the Run CR just created without any validation. From the TEP 61, the recommended feedback is to have some kind of async validation from the custom controller. So the not all the RUN CRs will be pending when one of the custom task validation webhooks is failing. Let me open another issue to track these enhancement.

To enhance the pipelineloop with embedded spec, we need

1. async validation from the custom controller
2. have custom task timeout when the custom controller is not available. Implement timeout for custom tasks. tektoncd/pipeline#3976

[Tomcli]

/lgtm

[Tomcli]

@pugangxa any last minute comment before I merge it?

[pugangxa]

@pugangxa any last minute comment before I merge it?

Thanks Tommy, no more comments from my side.

[Tomcli]

/approve

[google-oss-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ScrapCodes, Tomcli

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

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