https://pantsbuild.org/ logo
Join Slack
Powered by
I'm trying to figure out how to convert a helm pac...
# general
e
I'm trying to figure out how to convert a helm package workflow to pants. I've got my helm packages working, but I'm trying to configure the appVersion within the helm chart. Previously, I used 
helm package <path> --app-version="my_app_version"
. I can't seem to find a way to set this using pants.
🧵 1
I've tried using 
pants package <path>:: --helm-args='["--app-version=myspecialappversion"]'
but this doesn't work because the app-version arg is not allowed to be passed through
Copy code
luke@luke-dev:~/git/operations-core$ pants package src/helm/operations/:: --helm-args='["--app-version=myspecialappversion"]'
14:07:00.25 [ERROR] 1 Exception encountered:

Engine traceback:
  in root
    ..
  in pants.core.goals.package.package_asset
    `package` goal

Traceback (most recent call last):
  File "/home/luke/.cache/nce/ab1acf935c4cc43338c604ae7d0f6aa2419f2415d94eb9cae381601dbba70a61/bindings/venvs/2.22.0/lib/python3.9/site-packages/pants/core/goals/package.py", line 165, in package_asset
    packages = await MultiGet(
  File "/home/luke/.cache/nce/ab1acf935c4cc43338c604ae7d0f6aa2419f2415d94eb9cae381601dbba70a61/bindings/venvs/2.22.0/lib/python3.9/site-packages/pants/engine/internals/selectors.py", line 376, in MultiGet
    return await _MultiGet(tuple(__arg0))
  File "/home/luke/.cache/nce/ab1acf935c4cc43338c604ae7d0f6aa2419f2415d94eb9cae381601dbba70a61/bindings/venvs/2.22.0/lib/python3.9/site-packages/pants/engine/internals/selectors.py", line 174, in __await__
    result = yield self.gets
  File "/home/luke/.cache/nce/ab1acf935c4cc43338c604ae7d0f6aa2419f2415d94eb9cae381601dbba70a61/bindings/venvs/2.22.0/lib/python3.9/site-packages/pants/core/goals/package.py", line 116, in environment_aware_package
    package = await Get(
  File "/home/luke/.cache/nce/ab1acf935c4cc43338c604ae7d0f6aa2419f2415d94eb9cae381601dbba70a61/bindings/venvs/2.22.0/lib/python3.9/site-packages/pants/engine/internals/selectors.py", line 124, in __await__
    result = yield self
  File "/home/luke/.cache/nce/ab1acf935c4cc43338c604ae7d0f6aa2419f2415d94eb9cae381601dbba70a61/bindings/venvs/2.22.0/lib/python3.9/site-packages/pants/backend/helm/goals/package.py", line 53, in run_helm_package
    process_result = await Get(
  File "/home/luke/.cache/nce/ab1acf935c4cc43338c604ae7d0f6aa2419f2415d94eb9cae381601dbba70a61/bindings/venvs/2.22.0/lib/python3.9/site-packages/pants/engine/internals/selectors.py", line 124, in __await__
    result = yield self
  File "/home/luke/.cache/nce/ab1acf935c4cc43338c604ae7d0f6aa2419f2415d94eb9cae381601dbba70a61/bindings/venvs/2.22.0/lib/python3.9/site-packages/pants/backend/helm/util_rules/tool.py", line 467, in helm_process
    debug_requested = "--debug" in helm_subsystem.valid_args() or (
  File "/home/luke/.cache/nce/ab1acf935c4cc43338c604ae7d0f6aa2419f2415d94eb9cae381601dbba70a61/bindings/venvs/2.22.0/lib/python3.9/site-packages/pants/util/memo.py", line 123, in memoize
    result = func(*args, **kwargs)
  File "/home/luke/.cache/nce/ab1acf935c4cc43338c604ae7d0f6aa2419f2415d94eb9cae381601dbba70a61/bindings/venvs/2.22.0/lib/python3.9/site-packages/pants/backend/helm/subsystems/helm.py", line 200, in valid_args
    raise InvalidHelmPassthroughArgs(invalid, extra_help=extra_help)
pants.backend.helm.subsystems.helm.InvalidHelmPassthroughArgs: The following command line arguments are not valid: --app-version=myspecialappversion.

Only the following passthrough arguments are allowed:

  * --atomic
  * --cleanup-on-fail
  * --create-namespace
  * --debug
  * --force
  * --wait
  * --wait-for-jobs
  * --kubeconfig
  * --kube-context
  * --kube-apiserver
  * --kube-as-group
  * --kube-as-user
  * --kube-ca-file
  * --kube-token
  * --timeout
I considered a workaround by using a shell command to run 
yq
to inject the app version into the 
Chart.yaml
file and then depend on that shell command, but it didn't seem to work. It seemed that there was an issue between which Chart.yaml ended up in the helm process sandbox. The "raw" one from the repo was used. Maybe I don't quite understand how to use 
shell_command
to modify/replace a file before it goes into 
helm_chart
It seems that the 
helm_chart
target's 
chart
field must always refer to a file in the repository and cannot be modified by depending on a shell command. In the end, I just let my CI agent run 
yq
to modify the raw`Chart.yaml` file in the repository before calling 
pants package
. Would love to get this behavior native in pants when I have some time to take a look and understand the source, but for now, settling for a practical solution.
c
we have a field for version already, we could add a field for appversion too. It should be straightforward, basically duplicating the code for HelmChartVersion.
I'd be reluctant to add it as a passthrough arg, since the intention for those is that they're for global deployment options rather than target-specific args (that's why they're at the 
[helm]
option scope).
Would adding the field for appversion help? I think it might not depending on where the value comes from...
(Also for more on the implementation details, the 
helm_chart.chart
field is of type 
HelmChartMetaSourceField
which is a 
SingleSourceField
. That means it's looking for files on disk, which is why the output of a 
shell_command
can't be used for it.)
e
I would be happy with having a field for it (since I could use it with 
env(...)
). my thought with having a passthrough arg was that my workflow is such that I want to always tag all my helm charts with the same version (eg. to match a git tag) and release all my products in version lockstep, but I could see why this may not be the general case. I do agree it ought to be essentially a duplicate of the 
version
field.
Open in Slack
PreviousNext
Powered by