Future of Codeberg CI #843

New issue

JakobDev · 2022-12-21T13:16:20+01:00

JakobDev commented

2022-12-21 13:16:20 +01:00

As you mey all know, Codeberg uses Woodoecker for the CI, which is currently in Beta. Gitea is now working on a integrated CI. The new builtin CI will be based on act and is compatible with GitHub Actions. Another benefit of this work, is that existing external CI (like Woodpecker) will be better integrated into Gitea.

This rises one Question: Which CI system will Codeberg use? Will it stay on Woodpecker or will it switch to the new one?

Benefits of the new one:

It is fully compatible with GitHub Actions, so people migrating from GitHub (which is the platform most people migrating from) can keep their CI and do not need to learn a new one. This is a very huge benefit and will maybe more people motivate to change.
There are a huge amount of prebuild Actions that will likly work with the new Actions. That means, that Developers could use existing one instead of trying to build everything from ground. This can save time that the Developers can put into their Projects.

Benefits of staying with Woodpecker:

Users will not have to change their existing CI on Codeberg.
It is not connected to GitHub/Microsoft

I don't think Codeberg is willing to waste resources to keep 2 CI systems running, so a decission has to be made.

I know, this is a little bit early to talk about this, as I think it will take at leat one Year to be ready, but I think it's better to clarify things directly.

As you mey all know, Codeberg uses Woodoecker for the CI, which is currently in Beta. Gitea is now [working on a integrated CI](https://blog.gitea.io/2022/12/feature-preview-gitea-actions/). The new builtin CI will be based on act and is compatible with GitHub Actions. Another benefit of this work, is that existing external CI (like Woodpecker) will be better integrated into Gitea. This rises one Question: Which CI system will Codeberg use? Will it stay on Woodpecker or will it switch to the new one? Benefits of the new one: - It is fully compatible with GitHub Actions, so people migrating from GitHub (which is the platform most people migrating from) can keep their CI and do not need to learn a new one. This is a very huge benefit and will maybe more people motivate to change. - There are a huge amount of prebuild Actions that will likly work with the new Actions. That means, that Developers could use existing one instead of trying to build everything from ground. This can save time that the Developers can put into their Projects. Benefits of staying with Woodpecker: - Users will not have to change their existing CI on Codeberg. - It is not connected to GitHub/Microsoft I don't think Codeberg is willing to waste resources to keep 2 CI systems running, so a decission has to be made. I know, this is a little bit early to talk about this, as I think it will take at leat one Year to be ready, but I think it's better to clarify things directly.

👍 5

Bubu commented

2022-12-21 13:32:54 +01:00

Having both as an option wouldn't necessarily need to be wasteful if both can share the same runner resources. Or I'd there any fundamental reason this cannot work?

This leaves the task of having to maintain multiple CI systems, which doesn't sound too appealing either. We'll have to see further down the line if this has little enough maintenance requirements to make this feasible. Woodpecker still lacks a bunch of features that would allow opening this to more users (i.e. resource limits per users/orgs). Maybe that will be available in the gitea ci?

Having both as an option wouldn't necessarily need to be wasteful if both can share the same runner resources. Or I'd there any fundamental reason this cannot work? This leaves the task of having to maintain multiple CI systems, which doesn't sound too appealing either. We'll have to see further down the line if this has little enough maintenance requirements to make this feasible. Woodpecker still lacks a bunch of features that would allow opening this to more users (i.e. resource limits per users/orgs). Maybe that will be available in the gitea ci?

fnetX commented

2022-12-21 23:34:30 +01:00

I'd postpone this debate until the Gitea Actions is something more visible and we know how to deploy it.

I think we can have both options next to each other.

I'd postpone this debate until the Gitea Actions is something more visible and we know how to deploy it. I think we can have both options next to each other.

Ghost added the

s/Woodpecker

label

2022-12-24 11:06:51 +01:00

JakobDev commented

2022-12-28 12:26:41 +01:00

Having both options would mean that they have to be maintained both. If Codeberg ant to do this and have the mainpower, thats good. I asked, because I don't want to spend too much time migrating to Woodpecker, when it is bsoltee in one Year. SO let's keep this open until Gitea actions are in a more polished state.

👍 2

fnetX commented

2023-03-24 14:35:19 +01:00

Let me phrase it this way: We need more maintainers (also see https://codeberg.org/Codeberg/Projects). But if someone (better two) step(s) up to maintain the new Actions Runner and the necessary config, having multiple CI options is probably a bonus.

👍 1

fnetX referenced this issue from Codeberg-CI/request-access

2023-03-24 14:36:00 +01:00

CI request for a13xp0p0v/kconfig-hardened-check #317

fnetX referenced this issue from forgejo/discussions

2023-06-11 12:47:11 +02:00

Activating Forgejo Actions on Codeberg #36

fnetX commented

2023-06-30 01:11:44 +02:00

The actions runner has had serious security issues. If you want to learn about its security implications, this is a good starting point for reading: https://gitea.com/gitea/act/pulls/52#issuecomment-739310

Other than that, if someone steps up to track the progress and implement everything necessary on Codeberg's side, nothing holds against providing Actions compatible CI hosting at Codeberg.

The actions runner has had serious security issues. If you want to learn about its security implications, this is a good starting point for reading: https://gitea.com/gitea/act/pulls/52#issuecomment-739310 Other than that, if someone steps up to track the progress and implement everything necessary on Codeberg's side, nothing holds against providing Actions compatible CI hosting at Codeberg.

fnetX referenced this issue from Codeberg-e.V./requests

2023-07-02 20:17:26 +02:00

How to enable/use Forgejo Actions? #4

Codeberg.org added the

contributions welcome

label

2023-07-26 18:28:22 +02:00

Ghost commented

2023-09-06 05:09:58 +02:00

The actions runner has had serious security issues. If you want to learn about its security implications, this is a good starting point for reading: https://gitea.com/gitea/act/pulls/52#issuecomment-739310

I had a quick review. Upstream was closed the issue and Gitea stays open. The purpose of upstream project is running locally, so there is a different perspective if using the project for online services. I have no expertise on security, but question for you, is this security issue is a block for moving Actions adoption forword? If it is, stay for Woodoecker, because no solution for now and don't know how long gonna wait, and might be another security issues will come out in the future. Again, upstream is running locally, which don't care much about security.

Other than that, if someone steps up to track the progress and implement everything necessary on Codeberg's side, nothing holds against providing Actions compatible CI hosting at Codeberg.

Codeberg based on Forgejo, Forgejo forked Gitea, which is a chain. How to jump in the codebase on Codeberg side?

> The actions runner has had serious security issues. If you want to learn about its security implications, this is a good starting point for reading: https://gitea.com/gitea/act/pulls/52#issuecomment-739310 I had a quick review. Upstream was closed the issue and Gitea stays open. The purpose of upstream project is running locally, so there is a different perspective if using the project for online services. I have no expertise on security, but question for you, is this security issue is a block for moving Actions adoption forword? If it is, stay for Woodoecker, because no solution for now and don't know how long gonna wait, and might be another security issues will come out in the future. Again, upstream is running locally, which don't care much about security. > Other than that, if someone steps up to track the progress and implement everything necessary on Codeberg's side, nothing holds against providing Actions compatible CI hosting at Codeberg. Codeberg based on Forgejo, Forgejo forked Gitea, which is a chain. How to jump in the codebase on Codeberg side?

Ghost referenced this issue from forgejo/discussions

2023-09-26 23:29:00 +02:00

Issue from Gitea to Codeberg #62

chrboesch commented

2023-10-11 15:46:11 +02:00

A view from a user perspective: we moved our repo from Github to Codeberg. We had a CI enabled that tested functionality every night against a modified toolchain. Now I was able to implement this with Woodpecker and my experience with it has been very good. The only thing I missed is a description of how it works in general, supported by a block diagram or something else. But for me the big advantage is that I can do most of my work on my PC. After finishing the Docker container that automatically installs the toolchain, all I had to do was upload the Dockerfile to a codeberg repo and create a yaml file for the nightly build. It sounds simple and generally it was. I'll try to write a small tutorial in the next few weeks, but I don't think I'd want to go back to github actions. I think this flexibility and control is much better.

👍 6

n0toose commented

2023-10-11 20:34:45 +02:00

I'll try to write a small tutorial in the next few weeks, but I don't think I'd want to go back to github actions. I think this flexibility and control is much better.

If you license your tutorial with a license that is compatible to https://codeberg.org/Codeberg/Documentation (or otherwise libre, like a Creative Commons license), this could be integrated into our docs eventually (with a backlink if needed or if obligated by the license, of course).

> I'll try to write a small tutorial in the next few weeks, but I don't think I'd want to go back to github actions. I think this flexibility and control is much better. If you license your tutorial with a license that is compatible to https://codeberg.org/Codeberg/Documentation (or otherwise libre, like a Creative Commons license), this could be integrated into our docs eventually (with a backlink if needed or if obligated by the license, of course).

fnetX referenced this issue from Codeberg/Contributing

2023-10-15 23:55:27 +02:00

[Team] (Woodpecker) CI #42

nicksellen commented

2024-03-06 20:07:56 +01:00

One of the things that seems to be missing from the Woodpecker CI is caching (between runs), see https://github.com/LemmyNet/lemmy/issues/2652.

There is a drone plugin for it https://plugins.drone.io/plugins/volume-cache (using volumes somehow)

There is a Forgejo Actions plugin for it https://code.forgejo.org/actions/cache

I can't see any mention on the Woodpecker CI docs about caching. This might end up the dealbreaker for me, as it leads to a significant speed increase to be able to cache dependencies between runs.

Happy for any insight here, maybe I missed something! Otherwise it's a +1 towards moving towards Forgejo Actions from me!

One of the things that _seems_ to be missing from the Woodpecker CI is caching (between runs), see https://github.com/LemmyNet/lemmy/issues/2652. There is a drone plugin for it https://plugins.drone.io/plugins/volume-cache (using volumes somehow) There is a Forgejo Actions plugin for it https://code.forgejo.org/actions/cache I can't see any mention on the Woodpecker CI docs about caching. This might end up the dealbreaker for me, as it leads to a significant speed increase to be able to cache dependencies between runs. Happy for any insight here, maybe I missed something! Otherwise it's a +1 towards moving towards Forgejo Actions from me!

fnetX commented

2024-03-06 20:10:20 +01:00

I created a feature request about caching some years ago, no progress, indeed. https://github.com/woodpecker-ci/woodpecker/discussions/2295

👍 1

nicksellen commented

2024-03-06 21:50:41 +01:00

I managed a solution at least, by building an image that already has the app dependencies installed, then the ci run only has to sync what has changed, and I can periodically update the ci base image.

Test run time in CircleCI (with caching):

Test run time in Codeberg CI (using aforementioned preinstalling):

... although the non-preinstall test run is only another 40s slower, so maybe not worth the fuss :)

I managed a solution at least, by building an image that already has the app dependencies installed, then the ci run only has to sync what has changed, and I can periodically update the ci base image. Test run time in CircleCI (with caching): ![image](/attachments/6528208e-b300-4414-8d0d-72408f0acca8) Test run time in Codeberg CI (using aforementioned preinstalling): ![image](/attachments/44b8dd76-0744-4e37-8045-2bf7ad6b9f57) ... although the non-preinstall test run is only another 40s slower, so maybe not worth the fuss :)

image.png

3 KiB

image.png

2.8 KiB

👍 1

fnetX referenced this issue from Codeberg-CI/feedback

2024-07-30 18:48:32 +02:00

Forgejo Actions #192

fnetX commented

2025-01-03 16:16:21 +01:00

Most of this issue was clarified in https://codeberg.org/actions/meta/

fnetX closed this issue