#Still using old dagger release here 0 2
1 messages · Page 1 of 1 (latest)
HI @drowsy wing 👋 Would you be interested in migrating to one of the new Dagger SDKs? Node.js, Python, or Go?
that would be quite a bit of work, as this is run with jenkins pipeline already
I manually started the container on jenkins host via this workaround command: docker run --net=host -d --restart always -v $PWD/my-cert.pem:/etc/ssl/certs/my-cert.pem --name dagger-buildkitd --privileged moby/buildkit:latest. But each time this container got restarted unexpectedly, the whole workflow failed. how to ensure this command would be persisted on jenkins host, even when the moby container got restarted unexpectedly?
hmmm...is your project open source by any chance.
no, but it is very simple. docker build/pull/push stuff via cue file
Got it. That's what makes me think the new SDKs and new engine might make it much easier for you.
that means I would have to spend time to learn the new things. does it mean the cue way would not be supported later?
It's not under active development at this point.
I was looking back at how I've set up Jenkins in the past with Dagger (CUE version)...
I would prepare a Jenkins Agent image that had the Dagger CLI inside. Then I would use the Docker Socket from the Jenkins host from every agent container (using the Docker plugin).
That way, I didn't have to manage the Dagger Engines at all.
Dagger will also set up a docker volume to keep the cache state.
now we would use dagger-cue instead of dagger
problem is i have no control/say over jenkins or jenkins agent, I could only install the moby container on jenkins host.
ah so it seems the old dagger got renamed to dagger-cue.
Yes.
that explains why dagger do build failed. it would be dagger-cue do build with latest version
Just read more about https://github.com/dagger/dagger/issues/4105, and it seems there's no good solution to this issue, regardless it is dagger-cue or the new Dagger SDKs? Node.js, Python, or Go?
@drowsy wing Could you explain your use case for wanting to volume mount your internal CA certs? Is it because you need to auth to an internal private container registry from the Dagger Engine?
@mossy basin maybe you could comment on the future of the issue above 👆 or more specifically this one https://github.com/dagger/dagger/issues/4217
this is needed for all enterprise, who has internal CA certificate. When moby container failed, and then another dagger do build got run by jenkins, it by default would start a new moby/buildkit container, which has NO volume mount for CA certificate, thus all following run would fail. There's no way for us to control dagger do build so that it would auto start moby/buildkit container with CA certificate file volume mounted.