#Hi folks I am very Dagger curious and
violet birch
Regarding Pipelines, I know it's a platform limitation that the engine cannot be run in privileged mode, but I wonder if a Dagger process running in Bitbucket Pipelines could connect to another container runtime hosted elsewhere to execute its jobs? Or perhaps it would make more sense to just integrate Bitbucket with a different CI tool that supports Dagger if I really wanted to use it.
My guess is that for Windows jobs, dagger has no plans to support "docker on windows", but could it instead be a good idea to use a dagger setup to orchestrate CI jobs running on non-linux containers in other environments?
remote sandal
Regarding Pipelines, I know it's a platform limitation that the engine cannot be...
I’m not familiar with Bitbucket Pipelines, but the right answer may depend on where you’re hosting your CI runner. Is it on your own infrastructure (VM, kubernetes, other?) or as a black box managed service?
violet birch
Bitbucket is similar to the options provided by GitHub/GitLab. The primary option is managed/“black box”, which I see in this discussion has issues with supporting Dagger. I hadn’t considered that using a self-hosted runner could circumvent those limitations.
remote sandal
Bitbucket is similar to the options provided by GitHub/GitLab. The primary optio...
Yes, this is a pretty typical pattern. Even for CI platforms where Dagger can run on the black box managed service, there's always some limitation that can be solved by running the Dagger Engine and the CI runner side by side on the same VMs or kubernetes cluster.
Generally speaking, if you want to use Dagger in your production CI, regardless of CI platform, we recommend going for the "self-hosted runner" approach.
violet birch
Awesome, that's great to know. Am I correct that the way to point a dagger program at one particular runtime or another for running the dagger engine is just by making sure the local docker client is configured via env vars to communicate with that runtime?
remote sandal
Awesome, that's great to know. Am I correct that the way to point a dagger progr...
Not exactly, when you manually configure how to connect to the engine, you’re responsible for provisioning that engine yourself. That can be via the docker CLI or any other way (podman, containerd/nerdctl, kubernetes..) but you have to do it yourself.
The default behavior of auto-installing the engine with docker is a convenience, that typically you would not use in production
violet birch
Would you be able to point me to that documentation? I don’t think I’ve seen yet instructions for installing just the engine