seems to work here @Nipuna Perera

[half helm]

🧵 better late that never @surreal pond

the curl at the end failed though 🤔

[surreal pond]

hmm.. I am working with a copy of your module because I have to cater to the enterprise requirements too 🙂 So my testing is not 1:1. So far, the only major diff is the private registry mirrors. Seems to be working so far

[half helm]

now I'm getting this 😄

seems like by adding the cache volume I've opened a can of worms

[surreal pond]

yes I got this earlier

[half helm]

maybe changing the WithMountedCache back to WithMountedTemp for /var/lib/rancher will make it happier for you

[surreal pond]

let me try that

[half helm]

or using a previous version of the module

[surreal pond]

I think the problem is by the time I run helm install, the cluster is not ready

[half helm]

that could be a consequence of newer k8s versions

or helm

[surreal pond]

hm.. looks like the kubeconfig in that specific container is not valid. probably user error on my part

like when I spin up the kubectl container I can use the cluster... but not when I spin up helm

hm, I have the same code as you. When I do a server up from CLI and use another dagger call it works. But when the server.start() is in the same function it doesn't.

[half helm]

another thing which I should add to the example is to add a WithServiceBindin to the helm container. That way, the healthcheck will kick in and it should only allow helm to be called if the healthcheck passes

I think that should improve the overall resiliency of the pipeline

ok, got to a pretty consistent state where I constantly get INSTALLATION FAILED: cannot re-use a name that is still in use. Fixing that now

I ocassionaly saw the cluster unreachable you were getting Nipuna

ok helm upgrade --install is what I should use. Fixing that now

got to a fully working state. Pushing in a bit

[surreal pond]

server.start() is not needed with WithServiceBinding right?

and the endpoint

[half helm]

in the helm example that's needed for the final curl

[half helm]

btw this is incorrect. Start already checks for the healthchecks. Seems like there's indeed a race condition where the api doesn't seem to be fully up when helm upgrade runs

[surreal pond]

I think the healthcheck returns green even while cluster is bootstrapping... k3s server hands it off and says all good

[half helm]

yep. .

[surreal pond]

in my case it always says cluster unreachable

[half helm]

even before the kube config is written also I'd assume

[surreal pond]

Right! hence explains why it has the wrong config in my case

so I think we need consult the kube api server to see if the cluster is ready

[half helm]

yep, I'll add a small wrapper there. We need http(s) healthchecks for Dagger 😛

[surreal pond]

ok I'm gonna call it a week 😄 I'll meddle with this on Monday again. Thanks for your help! Have a great weekend 🙂

[half helm]

sure! u2!

[surreal pond]

btw, an enhancement to your module would be to allow for custom registry mirrors. I'll see if I can contribute that piece later

Registry mirrors and adding registry credentials for pods.

I got that part working on my end

[half helm]

fixed and publish Nipuna https://daggerverse.dev/mod/github.com/marcosnils/daggerverse/k3s@28eea1fcf3b6ecb38a628186107760acd717442f 🙏

[half helm]

❤️ would love the contrib

[surreal pond]

hey @half helm wanted to follow up. I made the same changes you did and it worked well! Now I can reproduce the nginx helm deployment every time.

[half helm]

glad it worked Nipuna! Looking forward to the other contribs you were mentioning on Friday 🙏