I have a Drone Docker setup on a Raspberry Pi 4. The runner only gets triggered if the .drone.yml contains a platform section set to linux and arm. Without this the default is linux and amd64 so the runner doesn’t get the job. Should not the routing be optional? If I decide to run Drone on a amd64 host I would have to rewrite all pipeline configurations.
In my opinion every runner should pick every job except the pipeline configuration requires a specific platform / runner. Then it would not matter on which platform the runner is working until the configuration says “only run on windows!”.
This is an interesting point, that if no platform is defined it gets picked up by any runner. I think this would work well for single-architecture installations. However, I think this would cause problems for multi-architecture installations. For example, Drone Cloud supports amd64, arm, arm64 and we are planning support for ppc64le and s390x. I doubt most developers expect their pipeline to get picked up by an s390x runner if the platform is unspecified in their yaml. We also have a strict policy that we do not want to introduce any breaking changes to Drone1.
I think this merits further discussion. Perhaps we could allow the system administrator to change the default from amd64 to arm / arm64 / etc. This could simplify configuration for single-architecture installations.
This being the case, how do I allow a task to run on a amd64 OR arm64 runner if one is available? Because at present, I have a seven cluster arm64 setup that is running drone-ci runners, but won’t accept tasks that my arm64 PC was running simply because of this behaviour. I would prefer if the arm64 worker isn’t running, or is busy, the arm64 workers would pick up tasks, and vice versa, rather than lock it to those workers only.
Personally, I would have expected that if a architecture wasn’t specified, then the CI task is architecture agnostic, and will use any available runner. But I do see how that could break things with existing setups if this wasn’t how it was implemented from day 1, and other architecture runners have been added to the pool.
So there’s no plugin or workaround? Not even some way to define both architectures, with a start timeout, and failure to execute not being a error? Sounds like I should be thinking about rebuilding my Jenkins CI stack!
I believe this would be problematic because not all docker images are available for all architectures; there is no guarantee a pipeline is portable across all architectures. If users of cloud.drone.io found their pipelines executing on ppc64le, for example, this would probably be very unexpected and cause many pipeline failures. I also believe there is some prior art to justify the current behavior, considering Travis and Circle behave in a similar manner.
The autoscaler solves this problem. You can dynamically provision and destroy instances based on demand, assuming you have elastic compute (aws, gcp, digitalocean, etc).
There is not. Pipelines are configured to execute on a specific os and architecture.
You should choose the right tool for your requirements. Drone and Jenkins are different tools, with different design decisions, and different tradeoffs. There is nothing wrong with choosing Jenkins if that is the best tool for your needs.
I made a typo there… fixed the other, didn’t see that one… should be 'if the amd64 worker isn’t running, the arm64 workers would pick up tasks. Sorry! That still wouldn’t solve the problem for me as I’m not running cloud compute but 100% self-hosted, but I do see how it would work if cloud hosted.
Thanks for the insight and brief Drone CI history lesson… important to know where you’ve come from! I fully appreciate that docker and arm/armhf/arm64 weren’t really on the radar in 2014. Given v1 didn’t go live until earlier this year I was surprised to see that this didn’t appear to have been considered, especially with the rapid update in ARM in the last 18 months, particularly in the microserver cloud hosting space.
I’ll probably have to work things so that I have an always on arm64 instance so that the main cluster doesn’t need to be always online. Jenkins had it’s benefits in using tags to choose hosts, but as you said, it has tradeoffs… and java was one of them. I really do like DroneCI for it’s simplicity, and hope something like this is thought off for a future iteration… perhaps being able to define multiple architectures, either via a comma separated list or maybe a boolean logic statement?
Having a comma separated list would be ‘simple’ in that it’s a list of the permissible architectures the runner could be on, and avoid the need to change the ‘default’ of amd64, hence no breakage of existing installations, and opening up another avenue for adoption. The alternative being to leave it as a consideration for V2.
When I say boolean logic, I meant something like this…
platform:
os: linux
arch: amd64 && arm64
Would trigger against both, or
platform:
os: linux
arch: amd64 || arm64
… would do either… which I really think would make it unnecessarily complex, but worth mentioning when thinking about this sort of thing. A comma separated list of ‘permissble’ architectures would be nice, without breaking anything.
Is this a thing nowadays? For now, I’ll only have one small runner on arm64, would love to set the default platform based on what I have not on what is possible in the world. Couldn’t this just be an environment variable on the server?
I fully appreciate that docker and arm/armhf/arm64 weren’t really on the radar in 2014. Given v1 didn’t go live until earlier this year I was surprised to see that this didn’t appear to have been considered, especially with the rapid update in ARM in the last 18 months, particularly in the microserver cloud hosting space.
Couldn’t this just be an environment variable on the server?