-
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
Update TaskRun status even if PipelineRun is done #757
Conversation
Due to the DAG execution model, it's possible for the PipelineRun to error while other TaskRuns are still executing. This change resolves a bug where the status for the other TaskRuns would not propagate to the PipelineRun if it has failed.
/ok-to-test |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dicarlo2, dlorenc 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 |
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 @dicarlo2 !!! i just left a couple comments b/c i was late to the party :)
@@ -176,22 +176,25 @@ func (c *Reconciler) Reconcile(ctx context.Context, key string) error { | |||
|
|||
if pr.IsDone() { | |||
c.timeoutHandler.Release(pr) | |||
c.Recorder.Event(pr, corev1.EventTypeNormal, eventReasonSucceeded, "PipelineRun completed successfully.") |
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.
hmm, looks like in this change this line got removed, so we no longer emit an event indicating successful completion? 🤔
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.
Oops, will submit a followup pr to fix that.
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!!
@@ -396,6 +399,23 @@ func updateTaskRunsStatus(pr *v1alpha1.PipelineRun, pipelineState []*resources.R | |||
} | |||
} | |||
|
|||
func (c *Reconciler) updateTaskRunsStatusDirectly(pr *v1alpha1.PipelineRun) error { |
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.
One note for the future (I'm pretty late to the party so not something we need to change now!) is that we generally try to avoid adding functionality at the reconciler level if we can: it's much easier to write (and read) test cases that don't require the entire reconciler to be setup (and the code tends to be simpler too)
@@ -479,10 +502,15 @@ func TestReconcileOnCompletedPipelineRun(t *testing.T) { | |||
c.Reconciler.Reconcile(context.Background(), "foo/test-pipeline-run-completed") | |||
|
|||
// make sure there is no failed events | |||
validateEvents(t, fr) | |||
validateNoEvents(t, fr) |
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 think this is b/c we don't have the success event anymore? (just not clear to me if this was an intentional change or not!)
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.
Yup, good catch - I was wondering how it was passing before.
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.
Oh actually, now that I think about it - I think I removed that event because it was emitted for both pipeline success and failure. Does that make sense?
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.
@dicarlo2 can you explain a bit more? I think we'd want to have an event in both cases - i.e. one event in each case, just to try to be very clear:
- Failure: event indicating failure
- Success: event indication success
(maybe that is already happening?)
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, to be clear, I removed it because we seemed to be emitting it in error, or at least it didn't make sense because regardless of success/failure we were always emitting a success event. Looking at it again, I think that would be the wrong place to emit an event anyways since we would essentially emit an event every time the controller resynchronizes and runs reconciliation on a completed/stale PipelineRun
.
Also, it appears we're already emitting a success/failure event here:
pipeline/pkg/reconciler/v1alpha1/pipelinerun/pipelinerun.go
Lines 374 to 379 in 0b42a42
before := pr.Status.GetCondition(apis.ConditionSucceeded) | |
c.timeoutHandler.StatusLock(pr) | |
after := resources.GetPipelineConditionStatus(pr.Name, pipelineState, c.Logger, pr.Status.StartTime, pr.Spec.Timeout) | |
pr.Status.SetCondition(after) | |
c.timeoutHandler.StatusUnlock(pr) | |
reconciler.EmitEvent(c.Recorder, before, after, pr) |
(and emitting it appropriately, i.e. it should be emitted only once on final success/error status change)
Add concaf to OWNERS
Changes
Due to the DAG execution model, it's possible for the PipelineRun to error while other TaskRuns are still executing. This change resolves a bug where the status for the other TaskRuns would not propagate to the PipelineRun if it has failed.
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.
Release Notes