-
Notifications
You must be signed in to change notification settings - Fork 85
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
Opt-out the kustomize feature via go build tags #299
Opt-out the kustomize feature via go build tags #299
Conversation
func (k *SkipKustomize) Run(ctx context.Context, _ filesys.FileSystem, _ string) ([]byte, error) { | ||
log := log.FromContext(ctx) | ||
log.WithValues("kustomizer", "SkipKustomize").Info("skip running kustomize") | ||
return nil, nil |
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 think you could return an error here, like fmt.Errorf("kustomize support is not compiled in (built with tag without_kustomize)")
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 like the error message. Updated
type EnabledKustomize struct{} | ||
|
||
// Run calls the kustomize/api library to run `kustomize build`. | ||
func (k *EnabledKustomize) Run(ctx context.Context, fs filesys.FileSystem, manifestPath string) ([]byte, error) { |
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.
FYI you can have the same function with a build tag and without the build tag.
So you could declare RunKustomize
in both.
One would have the build-tag //go:build without_kustomize
, the other would have the build tag //go:build !without_kustomize
.
Not a blocker though - and the refactoring is nice - but may be simpler in future.
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 the suggestion! I'm trying to use function/struct name to make the code self-explained. But I agree the EnabledKustomize
and SkipKustomize
structs may give duplicate info since the go file name ("disabled" "enabled) and the build tags have already explained the rationale. Updated!
344d81c
to
ca71a1c
Compare
ca71a1c
to
195304f
Compare
/assign @justinsb |
Thanks @yuwenma! /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: justinsb, yuwenma 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 |
LGTM 😄 |
Problems:
kustomize/api
. This library itself is commonly used by other libraries and users can encounter dependency conflicts if the other library uses a differentkustomize/api
release (what happened on my side and I cannot bump the other kustomize/api version).Description:
This PR split the kustomize hydration to 1. a generic kustomize build and 2. a no-op in different files; It adds a go build constraint
without_kustomize
to give users the ability to switch to opt out the kustomize feature in build time and no need to change their source code.Test:
This PR is tested using the guestbook example by changing the
make run
for the following two casesoutput
output
UPDATED