Closed perdasilva closed 2 months ago
Name | Link |
---|---|
Latest commit | d78e9a96a5f438c02f39e2514ed990eb7b3002c9 |
Latest deploy log | https://app.netlify.com/sites/olmv1/deploys/6696723a2fe9700008789218 |
Deploy Preview | https://deploy-preview-1016--olmv1.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
Attention: Patch coverage is 93.65079%
with 4 lines
in your changes missing coverage. Please review.
Project coverage is 73.29%. Comparing base (
422a740
) to head (d78e9a9
). Report is 2 commits behind head on main.
Files | Patch % | Lines |
---|---|---|
internal/action/error/errors.go | 92.00% | 2 Missing :warning: |
internal/action/helm.go | 94.59% | 1 Missing and 1 partial :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@perdasilva can you please add the results (logging) before and after the PR here. Which will help me better understand the difference in user experience.
@perdasilva can you please add the results (logging) before and after the PR here. Which will help me better understand the difference in user experience.
Went from:
CustomResourceDefinition "applications.argoproj.io" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "clusterextension-test": current value is "clusterextension-sample"; annotation validation error: key "meta.helm.sh/release-namespace" must equal "test": current value is "default"
To:
CustomResourceDefinition 'applications.argoproj.io' already exists in namespace ''
CustomResourceDefinition 'applications.argoproj.io' already exists in namespace ''
@joelanford mentioned that this logging is also not right because it does not the point right root cause to the user.
CustomResourceDefinition 'applications.argoproj.io' already exists in namespace ''
@joelanford mentioned that this logging is also not right because it does not the point right root cause to the user.
it would be good to have an example..? or alternatively, here is the line. Please feel free to suggest a change
Description
As part of #736 we'd like to mark helm errors when an installation fails due to conflict. This PR wraps the ActionClient interface we use to talk to helm and processes the errors returned give a set of programatic rules. So far, only the install conflict error translator is modeled
Reviewer Checklist