-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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(helm): add depBuild and template flags to HelmDeployFlags schema #9696
base: main
Are you sure you want to change the base?
feat(helm): add depBuild and template flags to HelmDeployFlags schema #9696
Conversation
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
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.
Hi team,
I'm currently reviewing this pull request and will provide my feedback in a few minutes. In the meantime, I'm giving you a summary of the pull request's content to help you and other reviewers quickly understand the changes and their intent.
This pull request, authored by art-shutter, aims to add new configuration options to the HelmDeployFlags
struct: DepBuild
and Template
. These additions allow users to supply extra command-line flags to the helm template
and helm dep build
commands when using Helm as a renderer.
Here's a breakdown of the changes:
docs-v2/content/en/schemas/v4beta12.json
: This file has been modified to include the newdepBuild
andtemplate
fields within theHelmDeployFlags
schema. Specifically:- Lines 2300-2311: Added the
depBuild
field, an array of strings for additional flags tohelm dep build
. - Lines 2318-2338: Added the
template
field, also an array of strings for additional flags tohelm template
. - Lines 2331-2334: Updated the
preferredOrder
array to includedepBuild
andtemplate
.
- Lines 2300-2311: Added the
pkg/skaffold/render/renderer/helm/args.go
: This file introduces new functions to handle the additional flags:depBuildArgs
: Constructs the arguments forhelm dep build
, including the new flags.templateArgs
: Constructs the arguments forhelm template
, incorporating the new flags.
pkg/skaffold/render/renderer/helm/args_test.go
: Added comprehensive unit tests for the new functions inargs.go
.pkg/skaffold/render/renderer/helm/helm.go
: Updated thegenerateHelmManifest
function to use the newdepBuildArgs
andtemplateArgs
functions and correctly handle the new flags.pkg/skaffold/schema/latest/config.go
: Modified to include theDepBuild
andTemplate
fields in theHelmDeployFlags
struct (lines 995-1004). Some minor cleanup was also performed on lines 1856-1893.
The changes are well-structured and the unit tests provide good coverage. I'll be looking at the implementation details more closely in my full review.
And now, a little haiku to lighten the mood:
Flags fly in the code,
Helm's commands now more flexible,
Builds run smoother now.
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.
This pull request adds depBuild
and template
flags to the HelmDeployFlags
schema, allowing users to provide additional CLI flags to helm template
and helm dep build
commands. The changes are well-implemented and address a user need. The schema changes are clear and the code additions are correct. The tests cover the new functionality appropriately.
Here's a summary of the changes I've suggested, referencing the Google Go Style Guide:
- Octal literals: Used octal literals for file permissions (e.g.,
0o666
instead of0666
). - Error Wrapping: Wrapped errors using
fmt.Errorf
for better context and stack traces.
0fd151a
to
00162ca
Compare
@@ -0,0 +1,58 @@ | |||
/* | |||
Copyright 2022 The Skaffold Authors |
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.
2025
@@ -0,0 +1,151 @@ | |||
/* | |||
Copyright 2022 The Skaffold Authors |
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.
2025
@@ -2318,6 +2327,15 @@ | |||
"x-intellij-html-description": "additional flags passed to (<code>helm install</code>).", | |||
"default": "[]" | |||
}, | |||
"template": { |
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.
do you need this, or did you add it just in case? if the second one, then it'll be better to remove it, because the more things you add - the more things that should be support, it is better to add as needed
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.
it's added here for consitency. If we don't add this for template then it means the commands helm upgrade
and helm install
behave differenly from helm template
. The latter is used primarily in gitops workflows. Leaving out template
would mean that we don't have feature parity when we use skaffold to ask helm to apply the changes directly and when we use helm to template only.
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.
if you need this - keep it) I meant that there is no need to add something if you don't it, because less code - easy to maintain)
|
||
outBuffer := new(bytes.Buffer) | ||
errBuffer := new(bytes.Buffer) | ||
|
||
// Build Chart dependencies, but allow a user to skip it. | ||
if !release.SkipBuildDependencies && release.ChartPath != "" { | ||
log.Entry(ctx).Info("Building helm dependencies...") | ||
if err := helm.ExecWithStdoutAndStderr(ctx, h, io.Discard, errBuffer, false, env, "dep", "build", release.ChartPath); err != nil { | ||
args := h.depBuildArgs(release.ChartPath) | ||
if err := helm.ExecWithStdoutAndStderr(ctx, h, io.Discard, errBuffer, false, env, args...); err != 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.
before: it can exit before dep build
on lines https://github.com/GoogleContainerTools/skaffold/pull/9696/files#diff-85ea74a2a849b3a19f3a1d48895e2b217f8b1105400c66cae3463582329d07faL165, 171, 175
after: it can exit after dep build
, because you moved all the errors inside the templateArgs
and call it after dep build
.
I'm not sure if it's ok or not, but to preserve the old behavior you can move the templateArgs
call before the dep build
.
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.
done
@@ -154,17 +154,6 @@ func (h Helm) generateHelmManifest(ctx context.Context, builds []graph.Artifact, | |||
return nil, helm.UserErr(fmt.Sprintf("cannot expand chart path %q", release.ChartPath), err) | |||
} | |||
|
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.
it'll be better to write tests for the generateHelmManifest
and refactor it after
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.
yeah, I'd agree. However, the method generateHelmManifest
is not atomic. This means the tests would be rather involved, including mocks of charts we pass in. This is exactly why I extracted the functionality that I was adding/modifying to a new method: it lets the tests be written in a saner manner
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.
yes, it was a good idea to extract them and test independently, but at the same time, you've changed the logic as I've explained here #9696 (comment)
let's wait for the mainainers)
Fixes: #8413
Description
This adds new configuration options to
HelmDeployFlags
struct,DepBuild
andTemplate
User facing changes
Users can now supply new option in the helm config to propagate additional cli flags to
helm template
andhelm dep build
commands when using helm as a renderer.