-
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
Improve performance of pipeline results #2690
Conversation
This PR cannot be merged: expecting exactly one kind/ label Available
|
1 similar comment
This PR cannot be merged: expecting exactly one kind/ label Available
|
The following is the coverage report on the affected files.
|
/kind cleanup |
@afrittoli Hi, would it be possible for you to review this PR? Thank you. |
Hi, thanks for this PR. Sure, it's already on my todo list :) |
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 this!
I've not managed to finish my review, I'll continue on Monday.
At a high level it looks good, the only concern I have it's with the missing error condition on failed spec.
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
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.
Thank you for this!
This is basically changing the updatePipelineResults
so that it works based on the pipeline run status instead of the pipeline run state. Building the pipeline run state requires fetching the spec again and re-running validation. This patch also reduces code duplication.
Performance-wise, after seeing #2740, I think that solving that might will provide the most part of the performance improvement; nonetheless I think having this still make sense, as even if fetching the spec is done from the informer, we still need to run validation.
@vdemeester @imjasonh @bobcatfish
/lgtm
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.
/lgtm
@othomann needs a rebase though 😅 |
I just rebase. Hopefully this is ok now with the tests. |
The following is the coverage report on the affected files.
|
@afrittoli @vdemeester should be all good. I rebased today. Thanks. |
/lgtm |
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!
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: afrittoli 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
Improve performance of pipeline results by using the pipeline status.
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 to build and release this image.
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