-
Notifications
You must be signed in to change notification settings - Fork 160
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
feat(verification): improve transient error handling #1650
Conversation
✅ Deploy Preview for docs-kargo-akuity-io ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1650 +/- ##
==========================================
+ Coverage 44.04% 44.19% +0.14%
==========================================
Files 207 208 +1
Lines 13133 13168 +35
==========================================
+ Hits 5784 5819 +35
Misses 7106 7106
Partials 243 243 ☔ View full report in Codecov by Sentry. |
This LGTM after merge conflicts are resolved. I may be PR'ing something similar for Promotions shortly. |
01c4bbf
to
d566baa
Compare
Has been rebased. |
d566baa
to
b7903a2
Compare
This commit improves the handling of transient Kubernetes API errors which may occur during the verification step of a Stage's current Freight. It does this by selectively returning errors which should be retried, causing the reconciler to not leave the `Verifying` phase and allowing it to retry the action it performed on the next reconciliation attempt. To allow the reconciler to distinguish a creation error from a failed attempt to retrieve results, closer inspection is performed on the existence of an `AnalysisRun` reference in the `VerificationInfo`. Signed-off-by: Hidde Beydals <[email protected]>
b7903a2
to
f673374
Compare
Addresses (part of) #1640
This improves the handling of transient Kubernetes API errors which may occur during the verification step of a Stage's current Freight.
It does this by selectively returning errors which should be retried, causing the reconciler to not leave the
Verifying
phase and allowing it to retry the action it performed on the next reconciliation attempt.To allow the reconciler to distinguish a creation error from a failed attempt to retrieve results, closer inspection is performed on the existence of an
AnalysisRun
reference in theVerificationInfo
.