kapitan: Kapitan errors while compiling HELM charts

Kapitan errors while compiling HELM charts

Steps to reproduce the behavior:

Configure a helm chart
run kapitan compile


Helm binding is not available. Run 'make build_helm_binding' to create it
Compile error: failed to compile target: poc01-istio

Expected behavior Chart gets generated

** Versions:**

$ kapitan--version
0.24.0

$ python --version
Python 2.7.16

$ pip3 --version
pip 19.1.1 from /usr/local/lib/python3.7/site-packages/pip (python 3.7)

I have used both the docker image `kapitan:ci` and user installed python kapitan

**Additional context**
see https://kubernetes.slack.com/archives/C981W2HD3/p1567418792016800

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 19 (15 by maintainers)

Most upvoted comments

Any news here?

ulyssescb on Jun 8, 2021

Totally agree on switching our docker images from alpine into slim debian!

But I’m not completely certain we need a command to build the helm binding. For pip users, I think it’s preferable to build and package both macOS and linux bindings with kapitan and write import logic to decide what to load on runtime.

ramaro on Sep 2, 2019

I see that this ticket is closed, but so far as I can tell, the issue still exists in the Pypi package. I don’t see a .so in the inputs/helm directory. Worse- I don’t see any steps in your CI scripts or setup.py to actually generate the file. Finally- the build.sh script errors out with missing dependencies, and I know nothing about golang to take a shot at fixing that. Is this the intended behavior?

pbecotte on Oct 30, 2019

@yoshi-1224 Yep! 💯

ramaro on Sep 2, 2019

++ for the -slim version. Unless there’s another requirement I’d recommend xenial which we also use in .travis.yml. That way we have the same everywhere and follow the same process to upgrade it all when the time comes.

uberspot on Sep 2, 2019

@uberspot

Also what if we switch our docker images to just debian as a way to have linking/compiling work properly?

I think this is a good idea. As far as I’ve looked into this, there is some issue with building c-shared objects on alpine (more specifically, using musl libc) using go. People tend to use something like debian:<version>-slim images which have the more common glibc as the alternative.

@ramaro What do you think?

yoshi-1224 on Sep 2, 2019