> However, you won’t be getting the advanced features like automation or other integration and collaboration features provided by GitHub.
Codeberg is working on CI and you can request early access. I've found it to work well and fast.
Codeberg is working on CI and you can request early access. I've found it to work well and fast.
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?
> This is the worst abuse of YAML
When was the last time you looked at k8s manifests?
Plus it’s a bit late to hate on YAML for CI config since it’s already being used by most services, such as:
- Concource
- Travis
- CircleCi
- GitHub Actions
- Gitlab
- AWS CodeBuild
Like it or not, the YAML-train left the station years ago. So Woodpecker isn’t doing anything here this isn’t already an established industry norm.
https://woodpecker-ci.org/docs/usage/pipeline-syntax
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.
To get what you want, you have to use the group option to group them together: https://woodpecker-ci.org/docs/usage/pipeline-syntax#group--... at which point frontend/backend would get run in parallel.
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.
> From what I’ve seen, the config uses dictionaries for concurrent pipelines.
You are wrong about that, see https://github.com/woodpecker-ci/woodpecker/issues/771
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.
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.
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.
https://woodpecker-ci.org/docs/administration/setup https://woodpecker-ci.org/docs/administration/agent-config https://woodpecker-ci.org/docs/usage/pipeline-syntax#platfor... https://github.com/woodpecker-ci/woodpecker/tree/master/pipe...
That, along with many messing advanced features pushed me towards gitlab.