Codeberg CI/CD Survey #428

Closed
opened 3 months ago by 6543 · 27 comments
6543 commented 3 months ago
Collaborator

We like to collect from our Community what CIs, they use and what they would propose for Codeberg.

A wish- & must-have-feature list would be nice to know too

We like to **collect** from our Community **what CIs**, they use and what they would **propose** for Codeberg. A wish- & must-have-**feature list** would be nice to know too <!-- --- Summary list started by @fnetx (WIP) ## Drone Why: - feature rich - nice frontend - many users reported positive experiences Why not: - licencing issues (mainly Open Core) ###### will continue later ... -->
6543 added the
public relations
infrastructure
labels 3 months ago
Collaborator

Also see #78 (there might be some useful thoughts in the discussion)

Also see #78 (there might be some useful thoughts in the discussion)
6543 changed title from Codeber CI/CD to Codeber CI/CD Survey 3 months ago

I'm fairly new in CIs/CDs, so won't be able to give a very detailed answer. So far, I have used Bamboo, which I dislike, and a little bit of Jenkins at work. Personally, I have dabbled a bit with Drone and Concourse CI. The latter being my preferred option, with a simple UI and a great cli which I'd love to see integrated with Codeberg.

In terms of features, I'd love to be able to build flatpaks automatically, as well as .rpm/.deb packages based on different branches. A cli first approach is desirable, or strong APIs documentation to programmatically create pipeline flows.

I'm fairly new in CIs/CDs, so won't be able to give a very detailed answer. So far, I have used Bamboo, which I dislike, and a little bit of Jenkins at work. Personally, I have dabbled a bit with Drone and Concourse CI. The latter being my preferred option, with a simple UI and a great cli which I'd love to see integrated with Codeberg. In terms of features, I'd love to be able to build flatpaks automatically, as well as .rpm/.deb packages based on different branches. A cli first approach is desirable, or strong APIs documentation to programmatically create pipeline flows.

Hi I use ansible awx and it's pipelines for CI/CD in my current position. I find it's workflows and tempaltes provide a really robust and flexible approach to CI/CD.

AWX seems a little prone to massive changes since it's release as FOSS but its pretty amazing what can be done with it.

Eliminating other tools and using the same automation/deployment platform for CI/CD is great for a few reasons.

  • The plethora automation modules can be directly intigrated into CI/CD process without custom scripting.

  • back and forth communication between the automation/inventory/deployment platform is elminated... like jenkins to forman etc etc.

The scope of what needs to be achieved in CI/CD needs to be discussed.. internal use vs external use. If external what parts to expose to public since offering up the entire awx might be alot of overhead etc etc etc. one really nice thing about awx is that any automation done through it becomes a restful URI so intigrating it with other CI/CD still works well if required.

I used this before AWX became FOSS
https://ansible-semaphore.com/

not to be confused with antoher CI/CD tool called semaphore. It will also be a fill fledge CI/CD tool in the near future, and can be already in some ways.

I belive the administrational overhead on ansible-semaphre could be less, but I have not investigated it in a few years.

This is a good blog that outlines why, it can somewhat be applied to semaphore.
https://keithtenzer.com/2019/06/24/ci-cd-with-ansible-tower-and-github/

Since have used Jenkins in history I do not see why AWX or soon semaphore couldnt replace it entirely and do a far better job.

Hi I use ansible awx and it's pipelines for CI/CD in my current position. I find it's workflows and tempaltes provide a really robust and flexible approach to CI/CD. AWX seems a little prone to massive changes since it's release as FOSS but its pretty amazing what can be done with it. Eliminating other tools and using the same automation/deployment platform for CI/CD is great for a few reasons. * The plethora automation modules can be directly intigrated into CI/CD process without custom scripting. * back and forth communication between the automation/inventory/deployment platform is elminated... like jenkins to forman etc etc. The scope of what needs to be achieved in CI/CD needs to be discussed.. internal use vs external use. If external what parts to expose to public since offering up the entire awx might be alot of overhead etc etc etc. one really nice thing about awx is that any automation done through it becomes a restful URI so intigrating it with other CI/CD still works well if required. I used this before AWX became FOSS https://ansible-semaphore.com/ not to be confused with antoher CI/CD tool called semaphore. It will also be a fill fledge CI/CD tool in the near future, and can be already in some ways. I belive the administrational overhead on ansible-semaphre could be less, but I have not investigated it in a few years. This is a good blog that outlines why, it can somewhat be applied to semaphore. https://keithtenzer.com/2019/06/24/ci-cd-with-ansible-tower-and-github/ Since have used Jenkins in history I do not see why AWX or soon semaphore couldnt replace it entirely and do a far better job.

I've been using Jenkins, CircleCi and GitHub Actions. I still use Jenkins for CD of privat projects. At work we migrated from CircleCi to GitHub Actions since they cost less.
I like about Jenkins that its open source other than that I don't think it has much going for it.
While I'd prefere using an open source CI on codeberg (since I'm here to get rid of closed source infrastructure in the first place) I realize how much work that might mean and woul'd not mind using a closed system for the first couple of years until we figure something else out.
If we'd decide not to integrate a CI I'd like a consense on what the best practice for using CI with codeberg is. Maybe a list of recommended CI providers that have been successfully tested with codeberg.
I don't care about CD being integrated in codeberg mostly because I don't trust any infrastrucure not under my full control with that kind of stuff.

I've been using Jenkins, CircleCi and GitHub Actions. I still use Jenkins for CD of privat projects. At work we migrated from CircleCi to GitHub Actions since they cost less. I like about Jenkins that its open source other than that I don't think it has much going for it. While I'd prefere using an open source CI on codeberg (since I'm here to get rid of closed source infrastructure in the first place) I realize how much work that might mean and woul'd not mind using a closed system for the first couple of years until we figure something else out. If we'd decide not to integrate a CI I'd like a consense on what the best practice for using CI with codeberg is. Maybe a list of recommended CI providers that have been successfully tested with codeberg. I don't care about CD being integrated in codeberg mostly because I don't trust any infrastrucure not under my full control with that kind of stuff.

ansible-semaphore also is desinged in go.

ansible-semaphore also is desinged in go.
hw commented 3 months ago
Owner

Supported CI/CD is listed in https://gitea.com/gitea/awesome-gitea#devops

Supported CI/CD is listed in https://gitea.com/gitea/awesome-gitea#devops
ashimokawa changed title from Codeber CI/CD Survey to Codeberg CI/CD Survey 3 months ago

DroneCI is pretty nice in combination with Gitea. I use it with my self hosted Gitea and it's quite simple.

DroneCI is pretty nice in combination with Gitea. I use it with my self hosted Gitea and it's quite simple.

The ability to store Terraform state in Gitlab is a nice feature, that I use a lot.

The ability to store Terraform state in Gitlab is a nice feature, that I use a lot.

Of the supported CIs, I've only used buildbot and Jenkins, and quite frankly, anything but those is probably fine... Drone looks nice.

Does Codeberg intend to host "runners" (builders) too? If so, I would really like to have BSD builders (in addition to the "mandatory" Linux builders). CI builds is the only way I have to ensure e.g. foot doesn't completely break between releases (i.e. when the distros build it...)

Of the supported CIs, I've only used buildbot and Jenkins, and quite frankly, anything but those is probably fine... Drone looks nice. Does Codeberg intend to host "runners" (builders) too? If so, I would _really_ like to have BSD builders (in addition to the "mandatory" Linux builders). CI builds is the **only** way I have to ensure e.g. foot doesn't completely break between releases (i.e. when the distros build it...)

DroneCI is pretty nice in combination with Gitea. I use it with my self hosted Gitea and it's quite simple.

I agree. It would also be nice if there was the possibility to use your own runners, but without the need to actually host a Drone instance. However, if Drone's licensing is a problem, Woodpecker would probably be a good "alternative"/fork.

> DroneCI is pretty nice in combination with Gitea. I use it with my self hosted Gitea and it's quite simple. I agree. It would also be nice if there was the possibility to use your own runners, but without the need to actually host a Drone instance. However, if Drone's licensing is a problem, [Woodpecker](https://github.com/laszlocph/woodpecker/) would probably be a good "alternative"/fork.

Super excited to hear that CI/CD support will be coming to Codeberg, I miss it sorely!

To me, being able to put the configuration directly into the repo (like GitHub, GitLab and Drone do it) as some kind of file (preferably YAML) is a must-have feature. Of course, there also needs to be a way to manage secrets (like passwords or SSH keys) outside of the repo.

Be aware that there’s currently some discussion in the community about CI/CD abuse by crypto miners. SourceHut stopped offering their builds system for free this month, for example. I’m pretty sure that Codeberg would have to fight similar battles against abuse if a free CI/CD service with hosted runners is introduced.

In my opinion, introducing CI/CD without hosted runners wouldn’t make a lot of sense. Instead of developing something from scratch (as suggested in #78), we should really look into using an existing tool.

I personally would be okay with paying a small fee to use hosted runners. I’d prefer something that’s based on actual usage (e.g. a prepaid system where I can buy CI/CD minutes in advance) rather than a fixed monthly fee, because I tend to only run few and infrequent builds. Based on current VPS pricings, I’d find something like 0.01 € to 0.05 € per hour appropriate. It’s more expensive than spinning up my own VPS, but more convenient.

Alternatively, make hosted runners a feature for e.V. members only.

Super excited to hear that CI/CD support will be coming to Codeberg, I miss it sorely! To me, being able to put the configuration directly into the repo (like GitHub, GitLab and Drone do it) as some kind of file (preferably YAML) is a must-have feature. Of course, there also needs to be a way to manage secrets (like passwords or SSH keys) outside of the repo. Be aware that there’s currently some discussion in the community about CI/CD abuse by crypto miners. [SourceHut stopped offering their `builds` system for free](https://man.sr.ht/ops/builds.sr.ht-migration.md) this month, for example. I’m pretty sure that Codeberg would have to fight similar battles against abuse if a free CI/CD service with hosted runners is introduced. In my opinion, introducing CI/CD _without_ hosted runners wouldn’t make a lot of sense. Instead of developing something from scratch (as suggested in #78), we should really look into using an existing tool. I personally would be okay with paying a small fee to use hosted runners. I’d prefer something that’s based on actual usage (e.g. a prepaid system where I can buy CI/CD minutes in advance) rather than a fixed monthly fee, because I tend to only run few and infrequent builds. Based on current VPS pricings, I’d find something like 0.01 € to 0.05 € per hour appropriate. It’s more expensive than spinning up my own VPS, but more convenient. Alternatively, make hosted runners a feature for e.V. members only.

Would like to tag @yarmo here, as I believe he has very good experiences with Drone for the https://codeberg.org/keyoxide/ project. For me Drone is the CI candidate that I am eyeing myself. Seems clean and intuitive, without overwhelming (and mostly unused) feature set.

Would like to tag @yarmo here, as I believe he has very good experiences with Drone for the https://codeberg.org/keyoxide/ project. For me Drone is the CI candidate that I am eyeing myself. Seems clean and intuitive, without overwhelming (and mostly unused) feature set.

Thanks for the reminder to participate, very excited about the prospect of CI/CD in Codeberg! Great suggestions in this thread, lots to investigate!

Based on my experience, my vote goes to integration with a Drone instance. It's easy to set up (two separate instances, one shared token between the two) and so far, still flawless. Plugins are available which the end-user needs to invoke in their config file, no need for the hoster to do anything.

There was a bit of uncertainty when Drone got acquired, but so far, it seems to be working out just fine.

Never used Woodpecker but given that it's a fork, I assume it will work similarly and, more importantly, interchangeably (which is the nice thing of loose integrations like these).

Regarding crypto miner abuse, I would absolutely be in favor of a fee. Perhaps by making it e.V. members only, as @scy suggested? I'd go as far as saying: if it is made free, I'll stick with my own instance, can't afford to risk build issues just because crypto miners are wreaking havoc on the CI/CD instance.

Thanks for the reminder to participate, very excited about the prospect of CI/CD in Codeberg! Great suggestions in this thread, lots to investigate! Based on my experience, my vote goes to integration with a [Drone](https://www.drone.io) instance. It's easy to set up (two separate instances, one shared token between the two) and so far, still flawless. [Plugins](http://plugins.drone.io) are available which the end-user needs to invoke in their config file, no need for the hoster to do anything. There was a bit of uncertainty when Drone got acquired, but so far, it seems to be working out just fine. Never used [Woodpecker](https://github.com/laszlocph/woodpecker/) but given that it's a fork, I assume it will work similarly and, more importantly, interchangeably (which is the nice thing of loose integrations like these). Regarding crypto miner abuse, I would absolutely be in favor of a fee. Perhaps by making it e.V. members only, as @scy suggested? I'd go as far as saying: if it is made free, I'll stick with my own instance, can't afford to risk build issues just because crypto miners are wreaking havoc on the CI/CD instance.
Poster
Collaborator

For CI abuse, we had the idear, of an aproval system. Only allow CI to repos, that we can confinm they are doing god & repo owners are trustworthy. And for pulls, a repo maintainer has to aprove.

I dont know a CI with that type of management features. But had in mind that we could extend woodpecker. Drone has license issues -nhave you tryed to compile it with OS Licensed files only :/

For CI abuse, we had the idear, of an aproval system. Only allow CI to repos, that we can confinm they are doing god & repo owners are trustworthy. And for pulls, a repo maintainer has to aprove. I dont know a CI with that type of management features. But had in mind that we could extend woodpecker. Drone has license issues -nhave you tryed to compile it with OS Licensed files only :/

I haven't tried to compile it, I'm one of those lazy docker people.

Drone has license issues

I have no idea what the Drone-licensing fuss is about and need a little bit more background—am I the only one out of the loop?

So apparently, we are talking about this: https://github.com/laszlocph/drone-oss?

If so... Yeah, I don't like the look of this. So the fully OSS version doesn't scale and has features cut, while the non-OSS version would scale but well, it's not OSS? Is this correct?

This was in 2019, any events since then that I am missing, @6543 ?

I haven't tried to compile it, I'm one of those lazy docker people. > Drone has license issues I have no idea what the Drone-licensing fuss is about and need a little bit more background—am I the only one out of the loop? So apparently, we are talking about this: [https://github.com/laszlocph/drone-oss](https://github.com/laszlocph/drone-oss)? If so... Yeah, I don't like the look of this. So the fully OSS version doesn't scale and has features cut, while the non-OSS version would scale but well, it's not OSS? Is this correct? This was in 2019, any events since then that I am missing, @6543 ?
Collaborator

Hunh, someone has created an opensource version of Githubactions https://github.com/ChristopherHX/runner.server

Hunh, someone has created an opensource version of Githubactions https://github.com/ChristopherHX/runner.server

Hello all,

I want to drop a CI server I've written myself into the mix: mvoCI (my very own Continuous Integration (server)). It is compatible to gitea and has the best integration with it (from the ones I bothered to implement hooks for). It is based on templates and the UI of flux-ci (https://github.com/NiklasRosenstein/flux-ci), which would also be compatible to gitea.

First things first: mvoCI does not do docker atm, and I would not trust it to compile untrusted code or run untrusted Makefiles/Buildscripts as is. It doesn't to isolation of builds very well (they are isolated by name of the repository, so only a single instance of a build for the same repository could run at the same time). It does however build Releases in gitea via its API. mvoCI does not interpret any meta-data or build scripts in the repo by itself, it sticks to a user-provided preset bash-script set on the web interface.

It does not present build-progress very well - as there are no dependencies between repositories or builds, it's quite limited, and every build is undertaken without any output, so no continuously updating logs like in gitlab. Builds are currently limited to a single machine, this could be extended easily to worker-instances.

Login is intended to be seperate, however it should be possible to add support for gitea as a Authentication Provider.

From the requirements there are a few things that would need to be done:

  • docker docker docker docker, should be "easy enough"
  • delegate building to worker machines
  • buy virtual hardware on demand, with everything attached to it, like monthly budgets
  • have dependencies, more then one build at the same time and triggered by the same events for multi-arch
  • maybe cache intermediate build-results for faster rebuilds

So, tl;dr: something like codeberg, where loads of unknown people post untrusted code, is not what I've written mvoCI for. It could in theory be extended to incorporate this setting a bit more, but you're probably better of with something already up and running.

I have my fair share of jenkins and gitlab experience and hated both for my personal needs, which however are different from what codeberg tries to achive.

Cheers.

Hello all, I want to drop a CI server I've written myself into the mix: [mvoCI](https://codeberg.org/snaums/mvoCI) (my very own Continuous Integration (server)). It is compatible to gitea and has the best integration with it (from the ones I bothered to implement hooks for). It is based on templates and the UI of flux-ci (https://github.com/NiklasRosenstein/flux-ci), which would also be compatible to gitea. First things first: mvoCI does not do docker atm, and I would not trust it to compile untrusted code or run untrusted Makefiles/Buildscripts as is. It doesn't to isolation of builds very well (they are isolated by name of the repository, so only a single instance of a build for the same repository could run at the same time). It does however build Releases in gitea via its API. mvoCI does not interpret any meta-data or build scripts in the repo by itself, it sticks to a user-provided preset bash-script set on the web interface. It does not present build-progress very well - as there are no dependencies between repositories or builds, it's quite limited, and every build is undertaken without any output, so no continuously updating logs like in gitlab. Builds are currently limited to a single machine, this could be extended easily to worker-instances. Login is intended to be seperate, however it should be possible to add support for gitea as a Authentication Provider. From the requirements there are a few things that would need to be done: * docker docker docker docker, should be "easy enough" * delegate building to worker machines * buy virtual hardware on demand, with everything attached to it, like monthly budgets * have dependencies, more then one build at the same time and triggered by the same events for multi-arch * maybe cache intermediate build-results for faster rebuilds So, **tl;dr**: something like codeberg, where loads of unknown people post untrusted code, is not what I've written mvoCI for. It could in theory be extended to incorporate this setting a bit more, but you're probably better of with something already up and running. I have my fair share of jenkins and gitlab experience and hated both for my personal needs, which however are different from what codeberg tries to achive. Cheers.
fnetX added the
service
label 2 months ago

Please don't go with Drone. It has an open core business model like GitLab which creates a conflict of interest with the community. If I was okay with that, I'd be using GitLab instead of Codeberg.

Please don't go with Drone. It has an open core business model like GitLab which [creates a conflict of interest with the community](https://media.libreplanet.org/u/libreplanet/m/why-i-forked-my-own-project-and-my-own-company-31c3/). If I was okay with that, I'd be using GitLab instead of Codeberg.
Collaborator

We have been mainly looking at Woodpecker by now, a Drone fork that seems to be well maintained, but it needs further investigation.

We have been mainly looking at Woodpecker by now, a Drone fork that seems to be well maintained, but it needs further investigation.

My main use case is cross compilation, and/or compilation on non-Linux OSes. Docker is great for a bunch of things, but if the CI in question allows for a runner on a dedicated non-Linux OS, that'd be helpful, too.

My main use case is cross compilation, and/or compilation on non-Linux OSes. Docker is great for a bunch of things, but if the CI in question allows for a runner on a dedicated non-Linux OS, that'd be helpful, too.

I personally love https://builds.sr.ht.

  • IMO very easy to use
  • it doesn't use Docker (it uses QEMU/KVM instead) -> CI with FreeBSD can easily be used
  • images are updated once a week
  • You can SSH into the machine after a build has failed for examination.
I personally love https://builds.sr.ht. * IMO very easy to use * it doesn't use Docker (it uses QEMU/KVM instead) -> CI with FreeBSD can easily be used * images are updated once a week * You can SSH into the machine after a build has failed for examination.

QEMU/KVM is nice for e.g. BSDs.

To expand on the earlier requirements:

I have a bunch of ARM machines that I need to build for. These fall into two categories: a) ones I cross-compile for, and b) ones that can host the compiler.

This latter category would just require a runner I can install on a local, NAT'd machine and make available to my repos only or some such. It's a security risk letting code that someone else may have checked in run in my network, but I could work my way around that somehow.

I also run Android builds. The issue here is similar in that cross-compiling is fairly easy to set up. Running on the emulator, however, is a tad more complex - you either have to start the emulator for the target platform for every run and then find the right emulator to deploy to and run on. Or you have several emulators running all the time, and still need to pick the right one.

Where both ARM (a) and Android are the same is that the build machine and the machine for running tests on are effectively different. In the Android case, it's also only reachable through a third machine (which may or may not be the build machine).

I'm not really expecting anything new here, but on the off chance that someone wants to spend effort on this, it would be very nice to have a sane setup here.

As a starting point, it would be nice:
a) If runners could indicate whether they can build or just execute. Of course, the precise image in use would still need to be configured correctly for the language in question. But a coarse build/execute-only would allow for some pre-selection here.
b) If runners could provide a kind of proxying interface that would e.g. be easy to implement for an emulator running on the same machine/somewhere else. The point is, it would be nice if one could avoid having to have special Android machines that run a runner; better to proxy the connection to emulator or physical device from a more regular machine.
c) If the CI/CD system could run different stages on different runners in a way that would allow me to e.g. cross-compile to aarch64 Android on a docker image, and run the artifact on an emulator/device with a matching architecture.

I hope this makes sense, and I'd be happy to discuss out-of-band or here or whatever is convenient.

QEMU/KVM is nice for e.g. BSDs. To expand on the earlier requirements: I have a bunch of ARM machines that I need to build for. These fall into two categories: a) ones I cross-compile for, and b) ones that can host the compiler. This latter category would just require a runner I can install on a local, NAT'd machine and make available to my repos only or some such. It's a security risk letting code that someone else may have checked in run in my network, but I could work my way around that somehow. I also run Android builds. The issue here is similar in that cross-compiling is fairly easy to set up. Running on the emulator, however, is a tad more complex - you either have to start the emulator for the target platform for every run and then find the right emulator to deploy to and run on. Or you have several emulators running all the time, and still need to pick the right one. Where both ARM (a) and Android are the same is that the build machine and the machine for running tests on are effectively different. In the Android case, it's also only reachable through a third machine (which may or may not be the build machine). I'm not really expecting anything new here, but on the off chance that someone wants to spend effort on this, it would be very nice to have a sane setup here. As a starting point, it would be nice: a) If runners could indicate whether they can build or just execute. Of course, the precise image in use would still need to be configured correctly for the language in question. But a coarse build/execute-only would allow for some pre-selection here. b) If runners could provide a kind of proxying interface that would e.g. be easy to implement for an emulator running on the same machine/somewhere else. The point is, it would be nice if one could avoid having to have special Android machines that run a runner; better to proxy the connection to emulator or physical device from a more regular machine. c) If the CI/CD system could run different stages on different runners in a way that would allow me to e.g. cross-compile to aarch64 Android on a docker image, and run the artifact on an emulator/device with a matching architecture. I hope this makes sense, and I'd be happy to discuss out-of-band or here or whatever is convenient.

Haven't tried it out, but there's also https://github.com/agola-io/agola

Haven't tried it out, but there's also https://github.com/agola-io/agola
dch commented 1 month ago

I also use BSD systems heavily, and would be interested in working with other people to set this up, for example, jail based on FreeBSD. I currently have aarch64 & amd64 systems doing this in-house. If there's interest in using this perhaps we can come to some arrangement.

I also use BSD systems heavily, and would be interested in working with other people to set this up, for example, jail based on FreeBSD. I currently have aarch64 & amd64 systems doing this in-house. If there's interest in using this perhaps we can come to some arrangement.

I'm gonna throw in two different thoughts. What you'll be doing here is enable people to get computation power for free - this could be used for bitcoin mining - which is a thing you really should not empower at all.

Second - I see trouble arising from getting (virtual) machines up, having Windows NT, Linux, some random BSDs, Mac, different architectures,... Having anything less than the best CI will restrict what platforms you'll be able to use. Gitlab uses containers and possibly virtual machines to get around that, I suspect that is not really easy and needs some powerful machines running only CI jobs.

So let's float an idea: make the people pay. To be frank - I don't mind, I have my own server with my own cheap CI on that. Bitcoin miners will mind, as they can't profit off that. People needing ARM, PowerPC or some random OS will probably also not mind paying for these services, which they cannot easily set-up for themselves. And if so, they still can upload relases built locally on their dev-machines. Also this would allow codeberg to become sustainable, even if not so many people donate money dirctly.

Let's be real: you will invest loads of money, time and sweat into setting up a generic, secure, reliable, easy-to-use and platform independent CI service, and you will invest even more time into keeping it running, updating the CI, fixing update conflicts, adapting it for user's needs, etc.

So, get real in what you want your service to look like and what requirements you can't or won't meet and what price you'd need to take for the service.

Cheers.

I'm gonna throw in two different thoughts. What you'll be doing here is enable people to get computation power for free - this could be used for bitcoin mining - which is a thing you really should not empower at all. Second - I see trouble arising from getting (virtual) machines up, having Windows NT, Linux, some random BSDs, Mac, different architectures,... Having anything less than the best CI will restrict what platforms you'll be able to use. Gitlab uses containers and possibly virtual machines to get around that, I suspect that is not really easy and needs some powerful machines running only CI jobs. So let's float an idea: make the people pay. To be frank - I don't mind, I have my own server with my own cheap CI on that. Bitcoin miners will mind, as they can't profit off that. People needing ARM, PowerPC or some random OS will probably also not mind paying for these services, which they cannot easily set-up for themselves. And if so, they still can upload relases built locally on their dev-machines. Also this would allow codeberg to become sustainable, even if not so many people donate money dirctly. Let's be real: you will invest loads of money, time and sweat into setting up a generic, secure, reliable, easy-to-use and platform independent CI service, and you will invest even more time into keeping it running, updating the CI, fixing update conflicts, adapting it for user's needs, etc. So, get real in what you want your service to look like and what requirements you can't or won't meet and what price you'd need to take for the service. Cheers.
Poster
Collaborator

So the Survey got quiete some good idears and thoughts ...

... the conclusion is:

  • restrict CI to aprofed repos by: bigger OpenSource Projects who need it & Codeberg Support them and/or to Codeberg Memgers ...
  • Custom Worksers, asap WoodPecker got support for it
  • Focus on Woodpecker as it's the FOSS sucessor of drone

Codeberg Already Support own self hosted CI so if there are extra needs nothing is holding a project back to do so

So the Survey got quiete some good idears and thoughts ... ... the conclusion is: - restrict CI to aprofed repos by: bigger OpenSource Projects who need it & Codeberg Support them and/or to Codeberg Memgers ... - Custom Worksers, asap WoodPecker got support for it - Focus on Woodpecker as it's the FOSS sucessor of drone Codeberg Already Support own self hosted CI so if there are extra needs nothing is holding a project back to do so
6543 closed this issue 1 month ago
Collaborator

Where can i follow the progress of Codeberg CI?

What is the plan of supporting different platforms like Windows, macOS and ARM?

Projects can't migrate to Codeberg because that's missing. (tenacity)

Where can i follow the progress of Codeberg CI? What is the plan of supporting different platforms like Windows, macOS and ARM? Projects can't migrate to Codeberg because that's missing. ([tenacity](https://github.com/tenacityteam/tenacity/issues/155))
Sign in to join this conversation.
No Milestone
No Assignees
20 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.