Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Emit events for all TaskRun lifecycle events #2329
Emit events for all TaskRun lifecycle events #2329
Changes from all commits
450cbc2
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
what if it was skipped? (maybe to be added?)
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.
A TaskRun is something that may only happen when a Pipeline is involved, so I did not look into that on this patch, where I focuses on events generated by the TaskRun controller.
There are two kind of skips:
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.
ah right, there's no taskrun at all, makes sense. those 2 skips are totally valid also. like you said, conditions aren't emitting events anyway, maybe we can revisit this then.
thanks!!
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'm a bit confused by the cases that don't require an event, do you think it might make sense to have an event every time the condition changes?
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.
The only cases where we do not emit an event are:
For the former I think we do not want an event, it may be we wrote the condition again and updated LastTransitionTime, but nothing really happened to the Condition, so no event.
For the latter, I could not think of a use case where afterCondition is nil, so I saw no point in adding that case now.
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.
is this just for testing? that's a bit unfortunate if so :( probably worth it tho?
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.
Yes, injecting fakes in the context is the same mechanism that we use to inject fake k8s client-go and other fakes.
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'm a bit confused why this call to
EmitEvent
is needed in addition to the other one a bunch of lines down in the same functionis it possible we can get away with one? i do like the idea of only having to call this logic once instead of being aware of 2 places it is called
or if it is required maybe a comment explaining why?
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.
You need to emit the event every time the condition changes, because - as things are today - you could have more than one condition change in one reconcile cycle.
That could change if we added extra conditions in future, i.e. instead of only using Succeeded (unknown/true/false) we could use Started and Running too. In any case, I think it's worth sending the event as early as possible. This reconcile cycle will go on to create a pod and run several API calls, so we may be losing a few hundreds milliseconds if we wait.
If something is looking for the event to update the status of a check in github, half a second later makes a difference.
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.
sounds like that's only in the started case? going from started to running - and shouldn't be expected from any other states?
anyway makes sense! i do think this is worth a comment explaining why the 2 calls but also wouldnt block on this
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.
Yeah, it's only in that case. I promise I'll add a comment in a follow-up 👼