-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement Pending PipelineRun status (TEP-0015) #3522
Conversation
Hi @jbarrick-mesosphere. Thanks for your PR. I'm waiting for a tektoncd member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @jbarrick-mesosphere !!
What do you think about maybe including an end to end test as well? https://github.com/tektoncd/pipeline/tree/master/test#end-to-end-tests
that would give you some flexibility to do something like: create a pipelinerun with a quick timeout, but pending, make sure it doesn't time out, then remove pending and verify it succeeds or times out or something (i.e. will make sure more pieces work together)
btw this is a relatively small PR so what im suggesting might be overkill but probably the fastest way to get this merged might be to break it up a little, e.g. if you had a PR with just the types and the validation, that could probably get merged a lot faster than this entire PR |
Thanks, if this makes it significantly easier for you as a reviewer I'm happy to do this, but I'm in no rush to get the API changes merged in without the implementation. |
/ok-to-test Logistics 😄 - please squash the commits |
The following is the coverage report on the affected files.
|
Thanks! I'll close my original PR after this is merged😸 |
docs/pipelineruns.md
Outdated
status: "PipelineRunPending" | ||
``` | ||
|
||
To start the PipelineRun, delete the `.spec.status` field. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say "unset the .spec.status
field, or update its value cancel it"
internal/builder/v1beta1/pipeline.go
Outdated
@@ -114,11 +114,16 @@ func PipelineDescription(desc string) PipelineSpecOp { | |||
} | |||
} | |||
|
|||
// PipelineRunCancelled sets the status to cancel to the TaskRunSpec. | |||
// PipelineRunCancelled sets the status to cancel to the PielineRunSpec. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo here: PipelineRunSpec
I notice that the TEP says it's a non-goal to support pending TaskRuns, "as that would requiring pausing the Kubernetes pods themselves" -- I think that's actually a bit misstated -- pending TaskRuns could just not create Pods, the same way that pending PipelineRuns just don't create TaskRuns. I think it's worth reconsidering implementing pending TaskRuns for consistency, or at least coming up with a better rationale for not doing so. |
I think I'm just over-applying this principle and this PR is pretty easy to review as it is 👍 |
Nice catch, yeah this is left over from when the proposal was to actually pause a running pipeline. |
Added an e2e test. 👍 |
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
5579f40
to
5986e9b
Compare
Allows creation of Pending PipelineRuns which are not started until the pending status is cleared. Co-authored-by: Tianxin Dong <[email protected]>
5986e9b
to
d5e6f66
Compare
The following is the coverage report on the affected files.
|
I see. Is the intention to support creating pending TaskRuns as well then? Either way, can you update the TEP with this? |
I don't currently have a use-case for this.
I can update the TEP, but that is outside of the scope of this PR. |
The initial TEP proposal PR says it will cover TaskRuns: tektoncd/community#203 Another recent TEP, tektoncd/community#228, assumes pending TaskRuns to limit concurrency during PipelineRun execution. |
I wrote the TEP, it doesn't say that.
That would be a discussion to have on that TEP's PR. |
Hey, sorry, I think I spoke imprecisely. I just meant the PR's title as merged was "Add a pending setting to Tekton PipelineRun and TaskRuns", so it seemed like we had intended to support it at some point. It's fine that the TEP's scope eventually narrowed -- better that than the opposite! -- and that the actually-merged TEP didn't cover pending TaskRuns at all. Your previous comment had been about lacking a use case, and I found the pipeline-concurrency TEP as a use case which was depending on pending TaskRuns, seemingly assuming they'd be added as part of your TEP. You're absolutely right that the pipeline-concurrency TEP is the place to discuss the addition of pending TaskRuns as a requirement for concurrency-limited pipelines. (To be clear, none of this discussion should block this PR, which otherwise looks great to me.) If you felt so inclined to extend this work in another PR to include pending TaskRuns, being as you have recent experience implementing such a change, I'm sure the authors of the pipeline-concurrency TEP would appreciate it. If that's outside your needs and you'd prefer the author of that TEP or the community at large to support pending TaskRuns, that's fine too. Thanks for your contributions of all kinds throughout this process. :) |
This should be ready for review. |
Do we have any plans to move forward this PR? 🤔 |
Any process of the PR, here we have a case and expect to leverage this feature: There is a specific |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I didn't realize this PR was still pending (pun intended), it looks great, and thanks for adding tests!
/lgtm
@@ -202,6 +207,8 @@ const ( | |||
// PipelineRunSpecStatusCancelled indicates that the user wants to cancel the task, | |||
// if not already cancelled or terminated | |||
PipelineRunSpecStatusCancelled = "PipelineRunCancelled" | |||
|
|||
PipelineRunSpecStatusPending = "PipelineRunPending" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I think it's worth adding a comment here similar to PipelineRunSpecStatusCancelled describing its purpose. Something like:
// PipelineRunSpecStatusPending indicates that the user wants to postpone starting a PipelineRun
// until some condition is met
Given how long this PR has been open and that I only have a nit about a comment, I'm happy to add that comment in a follow-up PR. /approve |
[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:
Approvers can indicate their approval by writing |
Changes
Implements the Pending PipelineRun status as described in TEP-0015. (based on #3223)
/kind feature
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
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