5 ms·
> However, you won’t be getting the advanced features like automation or other integration and collaboration features provided by GitHub. Codeberg is working o
by oever 4y ago
> 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.
https://codeberg.org/Codeberg-CI https://codeberg.org/Codeberg-CI
- jacooper 4y agoThe problem is Woodpecker is just not up to the standards of other CI systems. That, along with many messing advanced features pushed me towards gitlab.
- mathstuf 4y agoIs it just me or does this seem to only support Linux and leave all other platforms out to dry?
- mistrial9 4y agohere 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 ?
- mathstuf 4y agoProjects 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.
- vanviegen 4y agoI'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.
- mathstuf 4y agoThe "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.
- vanous 4y agoThere's the exec runner which can be used without any separation, so it's not very secure but doesn't require docker...
- pjmlp 4y agoIn 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.
- 0xbadcafebee 4y agoThe 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.
- mathstuf 4y agoI 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?
- 0xbadcafebee 4y agoYeah 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. https://woodpecker-ci.org/docs/administration/setup https://woodpecker-ci.org/docs/administration/setup https://woodpecker-ci.org/docs/administration/agent-config https://woodpecker-ci.org/docs/administration/agent-config https://woodpecker-ci.org/docs/usage/pipeline-syntax#platform https://woodpecker-ci.org/docs/usage/pipeline-syntax#platfor... https://github.com/woodpecker-ci/woodpecker/tree/master/pipeline/backend https://github.com/woodpecker-ci/woodpecker/tree/master/pipe...
- mathstuf 4y agoOk, so it sounds a lot like the GitLab-CI architecture then. Thanks.
- proxysna 4y agoNice 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.
- 0xbadcafebee 4y agoOoh yes it's the Drone clone! I haven't used Woodpecker, but Drone is fantastic. Can't wait to use this next time I need a self-hosted CI.
- 3np 4y agoNot really clone. It's a fork from the last commit under a free license, after which Drone changed theirs.
- remram 4y agoI 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?