feat(helm): add depBuild and template flags to HelmDeployFlags schema#9696
feat(helm): add depBuild and template flags to HelmDeployFlags schema#9696menahyouyeah merged 12 commits intoGoogleContainerTools:mainfrom art-shutter:add-flags-to-dep-build
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. |
ghost
left a comment
There was a problem hiding this comment.
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 newdepBuildandtemplatefields within theHelmDeployFlagsschema. Specifically:- Lines 2300-2311: Added the
depBuildfield, an array of strings for additional flags tohelm dep build. - Lines 2318-2338: Added the
templatefield, also an array of strings for additional flags tohelm template. - Lines 2331-2334: Updated the
preferredOrderarray to includedepBuildandtemplate.
- 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 thegenerateHelmManifestfunction to use the newdepBuildArgsandtemplateArgsfunctions and correctly handle the new flags.pkg/skaffold/schema/latest/config.go: Modified to include theDepBuildandTemplatefields in theHelmDeployFlagsstruct (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.
ghost
left a comment
There was a problem hiding this comment.
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.,
0o666instead of0666). - Error Wrapping: Wrapped errors using
fmt.Errorffor better context and stack traces.
| @@ -0,0 +1,58 @@ | |||
| /* | |||
| Copyright 2022 The Skaffold Authors | |||
| @@ -0,0 +1,151 @@ | |||
| /* | |||
| Copyright 2022 The Skaffold Authors | |||
| "x-intellij-html-description": "additional flags passed to (<code>helm install</code>).", | ||
| "default": "[]" | ||
| }, | ||
| "template": { |
There was a problem hiding this comment.
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.
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.
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)
| 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.
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.
| @@ -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.
it'll be better to write tests for the generateHelmManifest and refactor it after
There was a problem hiding this comment.
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.
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)
|
@plumpy @menahyouyeah could I get a review from maintainers please? is there a process to request it? |
menahyouyeah
left a comment
There was a problem hiding this comment.
Can you rebase? I just merged #9741 which creates a new schema. Then I can merge this PR.
| additionalArgs []string | ||
| flags latest.HelmDeployFlags | ||
| expected []string | ||
| shouldErr bool |
There was a problem hiding this comment.
nit: remove - this isnt being used
| }, | ||
| } | ||
| args, err := h.templateArgs(test.releaseName, test.release, test.builds, test.namespace, test.additionalArgs) | ||
| if test.shouldErr { |
There was a problem hiding this comment.
doesn't look like this is being used - can be removed
|
@menahyouyeah done |
|
Can you fix the failed unit tests? It just looks like the order of the helm render args changed so that's why the tests are failing |
fix: reorder the reassigment of args slice to keep the order of the flags
fixed the order of args in helm commands, since args are positional and expected to be at the positions they were (overrides must always come last) |
Just reran the tests and there are some failing - can you take a look? |
| return "", nil | ||
| } | ||
|
|
||
| func (h Helm) templateArgs(releaseName string, release latest.HelmRelease, builds []graph.Artifact, namespace string, additionalArgs []string) ([]string, error) { |
There was a problem hiding this comment.
The test suite for this function should include a case where the overrideArgs kick in
…verridesValuesFile function and add tests for Helm template args
| defer func() { | ||
| os.Remove(constants.HelmOverridesFilename) | ||
| }() |
There was a problem hiding this comment.
😱 just realized this will now remove the file as the location is returned, this will fail when run
There was a problem hiding this comment.
thank you! reverted this back to inlining
thanks, I did overlook an issue. It is now fixed and locally |
reran and there are still some broken tests |
from what I can tell based on the logs, this an auth/rate-limiting problem around docker hub, not the code itself |
|
Looks like this flag is used by the helm renderer but not the helm deploy. However the flag is configurable in both sections of Is this intentional or just an oversight? |
Fixes: #8413
Description
This adds new configuration options to
HelmDeployFlagsstruct,DepBuildandTemplateUser facing changes
Users can now supply new option in the helm config to propagate additional cli flags to
helm templateandhelm dep buildcommands when using helm as a renderer.