-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
🐛 (helm/v1-alpha): not scaffold webhooks conditionals manifests for projects without webhooks #4584
🐛 (helm/v1-alpha): not scaffold webhooks conditionals manifests for projects without webhooks #4584
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: camilamacedo86 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 |
2532ad1
to
44121b9
Compare
44121b9
to
e1333e2
Compare
@@ -96,7 +97,7 @@ func (s *initScaffolder) Scaffold() error { | |||
DeployImages: len(imagesEnvVars) > 0, | |||
HasWebhooks: hasWebhooks, | |||
}, | |||
&templatescertmanager.Certificate{}, | |||
&templatescertmanager.Certificate{HasWebhooks: hasWebhooks}, |
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 Camila, just wondered whether it is being updated due to scaffalding webhooks conditional issues.
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.
we are passing the value HasWebhooks here because then inside of the boilerplate to generate the Certs we just generate those which related to Webhook Sever only when we have Webhooks
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.
Looks good, but why this has failed. I suspect from here whether intended.
sigs.k8s.io/kubebuilder/v4/pkg/config
Incompatible changes:
- Config.HasWebhooks: added
Regards: #4584 (review) We can either do not change the API and keep the implementation inside of the plugin. |
pkg/config/v3/config.go
Outdated
@@ -172,6 +172,23 @@ func (c Cfg) HasResource(gvk resource.GVK) bool { | |||
return found | |||
} | |||
|
|||
// HasWebhooks checks if any stored resource has associated webhooks. | |||
func (c Cfg) HasWebhooks() bool { |
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.
/hold
Remove from the interface
e1333e2
to
949225f
Compare
/hold cancel It is good to fly now. |
949225f
to
0bbf858
Compare
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.
Hey @camilamacedo86, everything’s looking great! I just dropped a few tiny concerns.
{{ "{{- if and .Values.certmanager.enable (or .Values.webhook.enable .Values.metrics.enable) }}" }} | ||
{{- else }} | ||
{{ "{{- if and .Values.certmanager.enable .Values.metrics.enable }}" }} | ||
{{- end }} |
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.
Nit:
For the following two lines, how would you like we predefine variables as references for code readability?
{{ "{{- if and .Values.certmanager.enable (or .Values.webhook.enable .Values.metrics.enable) }}" }}
{{ "{{- if and .Values.certmanager.enable .Values.metrics.enable }}" }}
Such as:
{{- $certmanagerConditionWithHooks := `{{- if and .Values.certmanager.enable (or .Values.webhook.enable .Values.metrics.enable) }}` -}}
{{- $certmanagerConditionNoHooks := `{{- if and .Values.certmanager.enable .Values.metrics.enable }}` -}}
{{- if .HasWebhooks }}
{{ $certmanagerConditionWithHooks }}
{{- else }}
{{ $certmanagerConditionNoHooks }}
{{- end }}
Or perhaps, having these values defined in helpers.tpl
?
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 not sure if that would work well — we'd need to test it out first.
Since we're generating boilerplate to produce a template, it's a bit tricky to ensure consistent outputs.
Also, the certmanagerConditionWithHooks
and certmanagerConditionNoHooks
shouldn't be in the helpers.tpl
. The idea is to only include a Helm template with .Values.webhook.enable
when the project actually uses webhooks.
That said, if you'd like, we can definitely explore making changes in a follow-up.
If you see a clear path to improve things, we’ll likely need to update other parts as well to keep everything consistent and aligned with the same approach.
So for now, I think we can move forward with the current fix — but please feel free to open issues, PRs, etc., so we can address improvements more broadly.
mutatingWebhooks, validatingWebhooks, err := s.extractWebhooksFromGeneratedFiles() | ||
if err != nil { | ||
return fmt.Errorf("failed to extract webhooks: %w", err) | ||
} | ||
hasWebhooks := hasWebhooks(s.config) || (len(mutatingWebhooks) > 0 && len(validatingWebhooks) > 0) |
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.
Wondering if it’d be okay to change the name of the boolean variable so it’s not the same as the function hasWebhooks
Or, alternatively, update the function name instead, maybe something like webhooksConfigured
.
(Just in case this would help readability.)
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.
I changed the func name for hasWebhooksWith which seems the most appropriate.
… with webhook conditions when webhooks are not used
0bbf858
to
8e0dc31
Compare
HI @Kavinjsir I think we can merge this since it fixes the issues, looks for improvements, etc, in follow-up, wdyt? Thank youvery mucht for your time. |
Since the comments have been addressed and there were no objections to the fix, I'm going ahead and merging this so we can get it into the next release. That said, we can always iterate and improve on it in a follow-up as needed. Please feel free to open new PRs if you have suggestions or improvements in mind — always happy to review! |
d90d095
into
kubernetes-sigs:master
Closes: #4582