Add TEP Test Framework for Tasks

[jlux98]

No description provided.

[tekton-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign dibyom after the PR has been reviewed.
You can assign the PR to them by writing /assign @dibyom 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:

• teps/OWNERS

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

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: jlux98 (a946571, 1f81b49, 8c6b055, 61af912, 7e4c3f0, cacc59d, 14a927e, a03a3c5)

[jlux98]

/kind TEP

[jlux98]

I know, that having a PR with the whole proposal already filled out is not the preferred way to do it and that it's better to wait, until the initial summary and proposal is discussed and merged before adding the design section.

But as I had already put a lot of thought into the design and written out the section I thought it better to publish it quickly and get feedback instead of waiting for feedback on the initial proposal and then having to wait even longer for feedback on the rest.

[afrittoli]

@jlux98 Thank you for your proposal.
Did you receive any feedback on this? If not, I apologise for the delayed response.
is this still something that you're interested in? If so, I will spend some time reviewing your proposal.

[jlux98]

@afrittoli Thank you for your response.

I did not receive feedback on this proposal yet and it is still something I am interested in, as the feature described in this TEP will be the topic of my bachelor's thesis and ideally I'd like to design and implement it in a way where after I'm done the code can be merged into the official repo with as few changes as possible.

I pushed a small-ish revision today (touching up some of the examples for proposed API objects and rewording some paragraphs to hopefully flow better) and would be really glad, if you could take the time to have a look at the proposal.

[jlux98]

@afrittoli did you already have to time to look into the proposal?

I hope me asking doesn't come off as rude and I'm not doing it out of impatience. The reason why I'm asking is because as I wrote in my earlier comment the test framework described here will be the topic of my Bachelor's thesis, but what I didn't write is that I'll have to start implementing the feature in 3-4 weeks.
So if you were able to give me the first wave of feedback before then, that would be greatly appreciated - if not then that's still alright, I might be able to still incorporate the feedback into my thesis. And even if the feedback comes too late for that, then I'll compare the final product of the thesis to the feedback and go from there.

[waveywaves]

/assign

[vdemeester]

@jlux98 Thanks for this TEP and sorry for the late review. That's an interesting approach and I would love to see some experiments around this. I had a few questions, as well as:

Where would we want this to live ? in tektoncd/pipeline or in a sibling project ?

cc @tektoncd/core-maintainers

[vdemeester]

Do we plan to support resolvers here ?

[vdemeester]

Well, the controller of these new object could also directly do a kubectl or call the API just like any other client would.

[vdemeester]

One alternative that I don't see here, is to have something similar but without Kubernetes objects (and thus no reconciler, more imperative approach). I would like to weight pros and cons of those two approaches.

[tekton-robot]

@jlux98: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.