Nice to Woodpecker CI getting some traction. Great software for selfhosted ci. Simpler to start than Jenkins, not as flexible ofc, but most projects do not require that amount of flexibility and footguns. Woodpecker one of the best tools for small/medium self-hosted CI's out there atm.
I just took one look, I had never heard of it before, and... it's depending on the serialization order of steps in the YAML to run pipelines?! What fresh hell is this?
Loading the YAML file in a language where dictionaries/hashmaps don't preserve the insertion order and serializing again will break your file? How could they fail at such a basic step of making a YAML-configurable CI system?
This is the worst abuse of YAML I have ever seen. Was putting `-` in front of each step too obvious?
I am not hating on the whole of YAML, but the way they are misusing it in Woodpecker. None of those other services you mention are doing something this bad, e.g. relying on parts of YAML that are NOT standard (ordering of elements in a dict) and not supported by some languages/libraries.
> From what I’ve seen, the config uses dictionaries for concurrent pipelines.
Oh wow. You’re right. That is dumb. When I glanced over the example config file it looked like frontend and backend was intended to run in parallel (because that would have been the sensible way to design it).
It’s such a shame that the authors aren’t receptive to the problem because the longer they leave it the bigger the issue to change it will be.
The problem here is that if you load this YAML, modify it in code, and write it back out, but use a library or language that doesn't keep the ordering of the two entries the same, they will run in the wrong order.
As in their example: backend will be built, followed by frontend. Serially. Those are two different steps.
If instead you loaded this file and saved it without keeping the dictionary ordering the same, it is possible that frontend would not get built before backend.
Gitlab CI requires you to define your stages up-front, and tasks in the same stage all get executed at the same time.
On Github CI all tasks get executed in parallel by default, unless you specify a needs dependency at which point it will run the steps as required to meet those needs requirements.
I'd guess Linux is the most important platform for most customers. Also, it's probably the easiest and least expensive platform to support. I'd be very surprised if they'd picked another platform to support in their initial release of this feature.
The "every job uses a Docker container" is what worries me. Because the other two certainly don't have a robust container mechanism. Sure, Windows has something, but it is a far cry from "pick a distro, install some stuff, and call it a day" because there's some blessed image that supports installing .NET stuff and if you don't base on that, you're SoL (at least last I checked). And that's even ignoring the lack of rendering if you need it or the filesystem performance hit they seemed to be plagued with.
In the event of things going nasty with export regulations, it appears we are left with FOSS UNIX clones, and ISO/ECMA based programming languages, or those independent from corporate stewardship.
The underlying tech (Woodpecker) supports running tasks on Linux, MacOS, and Windows. It seems like they are still just in the testing phase, maybe they need a customer to run builds on all 3.
I don't see any docs about that. How is the `image` value used on macOS and expected to contain some usable macOS filesystem layout? Are you expected to SSH to a machine running the target platform from a Docker container and run the commands that way?
Yeah the docs are lacking. The way Woodpecker works is, there is a Server, that is sort of the "manager"; you only run one of these. You run one Agent on each host that you want builds to happen on. The Agent then executes the steps of your Pipeline on a "platform", which is an Agent running on a particular OS.
By default an Agent just wants to execute jobs in a Docker container, using the docker backend. But there are multiple backends. To run a build on Windows/MacOS, you would download the Go binary for the Agent for that platform, and execute it with the right environment variables to specify the local backend.
I think a lot of this functionality is just now getting added to Woodpecker so it's not been documented. It's been in Drone for a long time, but the fork is from a while ago.
here in the USA, Apple and Microsoft repeatedly lock out Linux|*nix from interoperability, marketing, transparency and more .. Linux Foundation appears to be a marketing club for Fortune 500.. where is this perspective ? You developers must include proprietary duopoly in any "open" effort but wait at the back door until I return and tell you what I want to ?
Projects I work on are cross-platform. When evaluating or comparing CI solutions, is that not a requirement to consider?
And I'm not saying that not supporting yet is a problem, but the docs saying "everything happens in Docker" implies a lack of forward-thinking in the design of the system that wholly excludes working elsewhere (including FreeBSD or other FOSS platforms).
Apparently it is being supported, but the docs will need some clarification now that some of the advertised assumptions are no longer going to be true.
Codeberg is working on CI and you can request early access. I've found it to work well and fast.
https://codeberg.org/Codeberg-CI