-
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
Initial Implementation of conditionals #1093
Conversation
The following is the coverage report on pkg/.
|
Pretty nice coverage boost! :D It looks like the coverage for test/builder/pipeline.go went down which I think means we are missing the test for what you've added to the builder (we do test the tests in this case XD). Would be nice to cover the additions to test/controller.go but that can be hard 😅 |
Nice work! |
@m1093782566: GitHub didn't allow me to request PR reviews from the following users: m1093782566. Note that only tektoncd members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this:
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. |
3f316b0
to
d519652
Compare
The following is the coverage report on pkg/.
|
This commit refactors the labels, annotations, default timeouts, and service account fields from taskruns into helper functions. This will allow us to easily reuse some common defaults for regular taskruns as well as those created for conditionals in tektoncd#1093
The following is the coverage report on pkg/.
|
This commit refactors the labels, annotations, default timeouts, and service account fields from taskruns into helper functions. This will allow us to easily reuse some common defaults for regular taskruns as well as those created for conditionals in tektoncd#1093
This commit refactors the labels, annotations, default timeouts, and service account fields from taskruns into helper functions. This will allow us to easily reuse some common defaults for regular taskruns as well as those created for conditionals in tektoncd#1093 Signed-off-by: Dibyo Mukherjee <dibyo@google.com>
This commit refactors the labels, annotations, default timeouts, and service account fields from taskruns into helper functions. This will allow us to easily reuse some common defaults for regular taskruns as well as those created for conditionals in tektoncd#1093 Also, this replaces some of the TestReconcile_ funcs that were testing only the functionality in these new helper functions with their own dedicated unit tests Signed-off-by: Dibyo Mukherjee <dibyo@google.com>
This commit refactors the labels, annotations, default timeouts, and service account fields from taskruns into helper functions. This will allow us to easily reuse some common defaults for regular taskruns as well as those created for conditionals in tektoncd#1093 Signed-off-by: Dibyo Mukherjee <dibyo@google.com>
This commit refactors the labels, annotations, default timeouts, and service account fields from taskruns into helper functions. This will allow us to easily reuse some common defaults for regular taskruns as well as those created for conditionals in tektoncd#1093 Signed-off-by: Dibyo Mukherjee <dibyo@google.com>
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
/test pull-tekton-pipeline-build-tests |
/hold cancel |
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.
Looking great! I think all of my comments are pretty minor things about docs or adding comments, generally looks like it's pretty much ready to go! 🎉 🎉 🎉
if !cc.IsSuccessful() { | ||
t.Fatal("Expected conditionCheck status to be done") | ||
} | ||
} |
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.
nice :D
c.Recorder.Eventf(pr, corev1.EventTypeWarning, "ConditionCheckCreationFailed", "Failed to create TaskRun %q: %v", rcc.ConditionCheckName, err) | ||
return xerrors.Errorf("error creating ConditionCheck container called %s for PipelineTask %s from PipelineRun %s: %w", rcc.ConditionCheckName, rprt.PipelineTask.Name, pr.Name, err) | ||
} | ||
} |
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'll play around with this some more, but what do you think about refactoring this in a follow-up?
Sounds good to me :D Thanks for looking into it :)
|
||
func (e *ConditionNotFoundError) Error() string { | ||
return fmt.Sprintf("Couldn't retrieve Condition %q: %s", e.Name, e.Msg) | ||
} |
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.
ResolvePipelineRun definitely does a lot (e.g. resolving tasks, taskruns resources, and now conditions and checks). I'm open to ideas on simplifying/modularizing this. At the moment though, we need this in order to build the full PipelineRunState in one call which is then used by the reconciler.
kk maybe we can refactor it in follow up PRs! For me the most appealing option is to have multiple Resolve
functions, each resolving a different type of thing, each being called by the Reconciler - then the Reconciler will know what kind of error message to set cuz it will know what kind of thing its trying to reconcile. Not super important tho!
@@ -113,6 +114,32 @@ func TestPipelineRun(t *testing.T) { | |||
// 1 from PipelineRun and 1 from Tasks defined in pipelinerun | |||
expectedNumberOfEvents: 2, | |||
pipelineRunFunc: getHelloWorldPipelineRun, | |||
}, { | |||
name: "pipeline succeeds when task skipped due to failed condition", |
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 for adding this! i think i derped a little bit when I suggested this be an end to end test vs. an example: i though the pipelinerun would end up failing (therefore wouldnt work as an example) but i forgot that a failing condition actually doesnt affect the success of the PipelineRun 🤦♀ anyway tho i think either is fine :D
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.
Well, this led me down a rabbit hole which led to #1130 which I think was what finally fixed the issue where creating and using a Condition immediately would always fail with a NotFound error. So, definitely worth it 👼
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
In this implementation, condition evaluations aka ConditionChecks are backed by TaskRuns. All conditionChecks associated with a `PipelineTask` have to succeed before the task is executed. If a ConditionCheck fails, the PipelineTask's associated TaskRun is marked failed i.e. its `Status.ConditionSucceeded` is False. However, the PipelineRun itself is not marked as failed. Signed-off-by: Dibyo Mukherjee <dibyo@google.com>
Instead of modifying the passed in pipelinerun's status, return the status to be updated. Also, updates the multiple status tests with conditionChecks to a single one with multiple inputs
The following is the coverage report on pkg/.
|
Signed-off-by: Dibyo Mukherjee <dibyo@google.com>
The following is the coverage report on pkg/.
|
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.
This is looking great to me! Thanks for responding to everything @dibyom 🙏🙏🙏
/lgtm
/approve
/meow space
|
||
This document defines `Conditions` and their capabilities. | ||
|
||
*NOTE*: This feature is currently a WIP being tracked in [#1137](https://github.com/tektoncd/pipeline/issues/1137) |
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.
🎉
PipelineTaskLabelKey = "/pipelineTask" | ||
|
||
// ConditionCheck is used as the label identifier for a ConditionCheck |
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 for adding these!!
In response to this:
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. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bobcatfish, dibyom 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
This commit adds an initial implementation for conditionals and depends on #1031.
In this implementation, condition evaluations aka ConditionChecks are
backed by TaskRuns. All conditionChecks associated with a
PipelineTask
have to succeed before the task is executed. If a ConditionCheck fails,
the PipelineTask's associated TaskRun is marked failed i.e. its
Status.ConditionSucceeded
is False. However, the PipelineRun itselfis not marked as failed.
Future PRs will add full support for passing in parameters, resource contents, and ability to read pipelinerun status from within the conditional container.
Part of #1019
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide for more details.
Double check this list of stuff that's easy to miss:
cmd
dir, please updatethe release Task and TaskRun to build and release this image
Release Notes
Adds a
Condition
type that can be used to conditionally execute tasks in a pipeline. Docs are in./docs/condtions.md
and./docs/pipelines.md