I’m currently working to make cibuildwheel work on drone, and to validate that on a constant basis in a cloud runner (while also supporting the same self-hosted pipelines), I need to know how flexible the cloud runner offering is to support a wide range of build environments.
Drone Cloud supports the following subset of runners:
Drone Cloud does not support:
* we plan to add support for digitalocean in the future.
Thanks for the quick reply!
I’ll apply these expectations when linking drone cloud to the repositories, are there any plans as of yet to support windows or macstadium builds on drone cloud in the future?
We have no immediate plans to support these runners on Drone cloud for different reasons.
Macstadium is an awesome service and we would love to offer support, however, Drone Cloud is completely free for open source projects and does not generate any revenue. We would have to pay for the service out-of-pocket, which is quite expensive, and difficult for us to justify at this time.
We have no plans to support docker pipelines on Windows primarily because we find Docker for Windows to be half-baked and not friendly for service providers. There are many issues with Windows, but the most notable is that Docker images on Windows are kernel-specific. This means we need to provide pools of separate Windows servers for every major Kernel version (1709, 1803, 1809, 1903, 1909, etc).
With that being said, I do envision us providing windows support through an AWS runner which would allow you to spawn AWS instances using your AWS credentials.
Interesting, thanks for that reply!
One more thing, this is never stated anywhere in the docs (afaik), but can a pipeline be defined without any type qualifiers? Or at least be able for both a kubernetes and a docker image to pick up the same job, as most of the time they’d be indistinguishable.
(Or maybe provide this functionality with a generic “container” type, food for ideas)
but can a pipeline be defined without any
typequalifiers?
To ensure backward compatibility with older versions of Drone, an empty type parameter defaults to a docker pipeline. However, for all intents and purposes the type should always be specified.
Or at least be able for both a kubernetes and a docker image to pick up the same job, as most of the time they’d be indistinguishable.
Each type of pipeline is responsible for defining its own custom syntax. The docker pipeline syntax and kubernetes pipeline system are similar, but they are treated as two separate specifications, and kubernetes pipelines have different syntax and different runtime behavior. There are no abstraction layers. Our goal was to create a learn once, run anywhere pipeline system, as opposed to a write once, run anywhere pipeline system.
Does it really have a radically different runtime behaviour? To me the final logical behaviour (run immutable container images under runc-supported runtime) seemed fairly the same. Indistinguishable to the end result.
Yes, one example is different networking behavior (with kubernetes, containers share the same pod network and services are accessible via localhost). It is very possible to write a pipeline that will work on docker but will not work on kubernetes and vice-versa. Creating a write once, run anywhere syntax sounds good in theory (we tried this for about 6 months), but in practice we ran into a number of small compatibility issues that resulted in support burden. We also received consistent feedback from our end users that they wanted us to expose kubernetes-specific syntax and features, which means there was little value in pursuing an abstraction tier. We also do not want the kubernetes runner to be held back by docker compatibility or vice-versa.
Gotcha, thanks for the answers, I’ll signify this alongside a link to the drone docs when making docs and description for the new supported CI environment for cibuildwheel.