:codeberg: Codeberg-hosted Forgejo-Actions :forgejo: #1702

fnetX commented 2024年11月14日 00:08:54 +01:00

Comment

Hi everyone! Forgejo Actions has matured a lot over the past year, and we think it's time to approach a hosted offer by Codeberg, next to our existing Woodpecker CI. We are looking forward to your feedback and suggestions, and we'll use this issue to communicate plans and progress.

The current CI/CD situation

Unfold to read more about the status quo

Codeberg offers hosted CI/CD using Woodpecker CI. Access is granted per user on request. It is a powerful CI/CD solution, based on an early version of Drone, but successfully enhanced by the community over the past years. The service is generously maintained by some Woodpecker developers on Codeberg's owned hardware.

Forgejo Actions is a new CI/CD implementation and integrated into the software. It is similar to GitHub Actions and a migration is usually easy (although they are not fully compatible!). It was initially developed with some controversy by Gitea Ltd. The Forgejo developers have picked up the effort and enhanced it over time, using it daily for powering their work (about one third of all tasks run at Codeberg.org originate from the Forgejo development).

Forgejo Actions makes it easy to connect own runners, and so many users already made use of the feature by connecting their own runners to Codeberg. Codeberg does not yet provide computing power for Forgejo Actions users.

Why hosted Forgejo Actions?

We have a working CI/CD offering with Woodpecker, which is used by a lot of projects on Codeberg and exists for several years now. However, there is an increasing number of people who are familiar with GitHub Actions and are in need for a libre replacement for it. Offering something similar allows for a more convenient migration out of GitHub.

Forgejo Actions is "baked" into Forgejo and has nice UI integration. Users of Codeberg find the option in their repository settings. Some are confused about our "official" CI offering having nothing to do with the integrated CI.

And, last but not least, having a second offer allows users to decide which to prefer and honours the work of the Forgejo developers.

What about the existing Woodpecker CI offer?

Both services will be maintained by independent teams, and there are no plans to retire the existing service. It depends on the availability and commitment of volunteers in the end, so we can't do any promises for either of the services.

I will follow up with more details about the concept.

### Comment Hi everyone! Forgejo Actions has matured a lot over the past year, and we think it's time to approach a hosted offer by Codeberg, next to our existing Woodpecker CI. We are looking forward to your feedback and suggestions, and we'll use this issue to communicate plans and progress. ## The current CI/CD situation <details><summary>Unfold to read more about the status quo</summary> Codeberg offers hosted CI/CD using [Woodpecker CI](https://woodpecker-ci.org/). Access is granted per user [on request](https://codeberg.org/Codeberg-e.V./requests). It is a powerful CI/CD solution, based on an early version of Drone, but successfully enhanced by the community over the past years. The service is generously maintained by some Woodpecker developers on Codeberg's owned hardware. Forgejo Actions is a new CI/CD implementation and integrated into the software. It is similar to GitHub Actions and a migration is usually easy (although they are not fully compatible!). It was initially developed with some controversy by Gitea Ltd. The Forgejo developers have picked up the effort and enhanced it over time, using it daily for powering their work (about one third of all tasks run at Codeberg.org originate from the Forgejo development). Forgejo Actions makes it easy to connect own runners, and so many users already made use of the feature by connecting their own runners to Codeberg. Codeberg does not yet provide computing power for Forgejo Actions users. </details> ## Why hosted Forgejo Actions? We have a working CI/CD offering with Woodpecker, which is used by a lot of projects on Codeberg and exists for several years now. However, there is an increasing number of people who are familiar with GitHub Actions and are in need for a libre replacement for it. Offering something similar allows for a more convenient migration out of GitHub. Forgejo Actions is "baked" into Forgejo and has nice UI integration. Users of Codeberg find the option in their repository settings. Some are confused about our "official" CI offering having nothing to do with the integrated CI. And, last but not least, having a second offer allows users to decide which to prefer and honours the work of the Forgejo developers. ## What about the existing Woodpecker CI offer? Both services will be maintained by independent teams, and there are no plans to retire the existing service. It depends on the availability and commitment of volunteers in the end, so we can't do any promises for either of the services. I will follow up with more details about the concept.

fnetX commented 2024年11月14日 00:33:55 +01:00

The concept for hosted Codeberg runners

Forgejo makes it easy to connect numerous runners and distribute them.
It is also trivial to distribute jobs across runners, but it is not trivial to benefit from caching if jobs are distributed (this can be configured, but it is not a widely tested setup yet).

We assume that we can have a somewhat efficient resource usage if we dedicated runners to the different use cases using labels and letting users choose which runner to use exactly.

Currently, we do not have effective abuse detection and prevention methods, so we'll start with strict timeouts. That said:

The initial setup will focus on lightweight and short convenience jobs. This means, we'll start hosting Forgejo Actions for things like

• building static pages and automating website deployments
• automating metadata checks for your repositories (automating things like issue labelling or other quick checks)
• spellchecks and (small) linters
• other helper tools such as release notes assistants etc

Especially for the small jobs, we expect it will save a lot of effort by not requiring everyone to set up a dedicated runner just for some tiny status checks. If you require more powerful CI, you can bring your own runner. You can also have them coexist, e.g. run status checks all the time on Codeberg's runner and launch your runner overnight when your server is otherwise idle.

Runner labels

Forgejo runners each bring one or multiple labels. They will have a prefix to avoid clashing with your own runners. They can be used in pipelines using a syntax like:

jobs:my-job:runs-on:codeberg-tiny

My idea is to have a set of labels which represent

• the exact specs of the machine (in case it is required to launch specific hardware specs)
• optional: -lazy variants to indicate a job does not need to run in realtime (they could be scheduled during times of low load or on offsite hardware during sunny days)
• optional: architecture (once we offer multiple, default is amd64)

Labels could be aliased for convenience and if the exact specs are not super important. For example, codeberg-tiny could be guaranteed to run at least on machines with 1 cpu, 1 GB of memory and with a timeout of at least one minute, but it might also run on more powerful hardware.

Open questions

We would like to learn more about your needs. Let us know things like

• what you would probably do with the offer
• how much resources your jobs need
• how much use of caching you would want to make
• how many runs you would spawn
• the maximum delay you'd like to wait for your jobs for
• ...

This will help figuring out the final concept for labels and runner setups.

One big issue might be abuse. Unlike with Woodpecker CI, there is no way to restrict access to CI to some users only. We think that starting with a "convenience" runner for small Actions, which will have tight limits, is a good start and unlikely to get abused. Something like 2 CPU cores, 2 GB of memory and a timeout of only a few minutes is probably not attracting everyone for abuse. At least I hope so.

Timeline

1. We will probably start first tests with Forgejo runners soon. A global runner might appear in a few days already.
2. We will ask you to test it, but it might go down or disappear from time to time.
3. Once proven somewhat stable, we'll offer a first runner and announce a set of available labels for you.
4. The first runner will be capped in resources and execution time to prevent abuse.
5. Once the platform and tooling matures, we will slowly expand capacity and available resources to match your needs. The future is open, and you can help shaping it.

## The concept for hosted Codeberg runners Forgejo makes it easy to connect numerous runners and distribute them. It is also trivial to distribute jobs across runners, but it is not trivial to benefit from caching if jobs are distributed (this can be configured, but it is not a widely tested setup yet). We assume that we can have a somewhat efficient resource usage if we dedicated runners to the different use cases using labels and letting users choose which runner to use exactly. Currently, we do not have effective abuse detection and prevention methods, so we'll start with strict timeouts. That said: The initial setup will **focus on lightweight and short convenience jobs**. This means, we'll start hosting Forgejo Actions for things like - building static pages and automating website deployments - automating metadata checks for your repositories (automating things like issue labelling or other quick checks) - spellchecks and (small) linters - other helper tools such as release notes assistants etc Especially for the small jobs, we expect it will save a lot of effort by not requiring everyone to set up a dedicated runner just for some tiny status checks. If you require more powerful CI, you can bring your own runner. You can also have them coexist, e.g. run status checks all the time on Codeberg's runner and launch your runner overnight when your server is otherwise idle. ## Runner labels Forgejo runners each bring one or multiple labels. They will have a prefix to avoid clashing with your own runners. They can be used in pipelines using a syntax like: ~~~yaml jobs: my-job: runs-on: codeberg-tiny ~~~ My idea is to have a set of labels which represent - the exact specs of the machine (in case it is required to launch specific hardware specs) - optional: `-lazy` variants to indicate a job does not need to run in realtime (they could be scheduled during times of low load or on offsite hardware during sunny days) - optional: architecture (once we offer multiple, default is amd64) Labels could be aliased for convenience and if the exact specs are not super important. For example, `codeberg-tiny` could be guaranteed to run at least on machines with 1 cpu, 1 GB of memory and with a timeout of at least one minute, but it might also run on more powerful hardware. ## Open questions We would like to learn more about your needs. Let us know things like - what you would probably do with the offer - how much resources your jobs need - how much use of caching you would want to make - how many runs you would spawn - the maximum delay you'd like to wait for your jobs for - ... This will help figuring out the final concept for labels and runner setups. One big issue might be abuse. Unlike with Woodpecker CI, there is no way to restrict access to CI to some users only. We think that starting with a "convenience" runner for small Actions, which will have tight limits, is a good start and unlikely to get abused. Something like 2 CPU cores, 2 GB of memory and a timeout of only a few minutes is probably not attracting everyone for abuse. At least I hope so. ## Timeline 1. We will probably start first tests with Forgejo runners soon. A global runner might appear in a few days already. 2. We will ask you to test it, but it might go down or disappear from time to time. 3. Once proven somewhat stable, we'll offer a first runner and announce a set of available labels for you. 4. The first runner will be capped in resources and execution time to prevent abuse. 5. Once the platform and tooling matures, we will slowly expand capacity and available resources to match your needs. The future is open, and you can help shaping it.

jornfranke commented 2024年11月15日 00:15:25 +01:00

How do you isolate the different runners? Are they on a shared machine or each runner is an own machine?
Is it using (rootless) Podman in the background?

How do you isolate the different runners? Are they on a shared machine or each runner is an own machine? Is it using (rootless) Podman in the background?

MichaelAgarkov commented 2024年11月15日 11:12:37 +01:00

Will the Forgejo Actions runner support large projects, and if so, will it have a Windows-based runner?

Will the Forgejo Actions runner support large projects, and if so, will it have a Windows-based runner?

fnetX commented 2024年11月15日 12:13:22 +01:00

How do you isolate the different runners?
Is it using (rootless) Podman in the background?

The current setup runs rootless podman in an LXC machine. The different runs rely on podman for isolation, different runners will be in separate LXC containers.

Are they on a shared machine or each runner is an own machine?

For the near future, we will have three physical servers and we will arrange runners to use the hardware most efficiently (Woodpecker CI is also in the equation).

Will the Forgejo Actions runner support large projects

Probably yes, but it requires more testing and ways to fight abuse.

will it have a Windows-based runner?

Codeberg is currently not running proprietary operating systems, and no one in the core team is familiar with working with those. I'm proud that Codeberg has yearly license fees of € 0. So it is very unlikely that we will offer official support for proprietary operating systems. It is more likely that we offer small RISC-V runners or similar experiments.

You can still bring your own runner, and we believe that having hosted GNU/Linux runners can already relieve projects.
A project supporting three operating systems including GNU/Linux would currently need to host three runners. In the future, they can offload the maintenance of the GNU/Linux runner to Codeberg. If you consider that some jobs (such as linting and testing) might only need to run on one OS, you can spin up the proprietary OS runners less often, for example only during release preparations and the final build.

> How do you isolate the different runners? > Is it using (rootless) Podman in the background? The current setup runs rootless podman in an LXC machine. The different runs rely on podman for isolation, different runners will be in separate LXC containers. > Are they on a shared machine or each runner is an own machine? For the near future, we will have three physical servers and we will arrange runners to use the hardware most efficiently (Woodpecker CI is also in the equation). > Will the Forgejo Actions runner support large projects Probably yes, but it requires more testing and ways to fight abuse. > will it have a Windows-based runner? Codeberg is currently not running proprietary operating systems, and no one in the core team is familiar with working with those. I'm proud that Codeberg has yearly license fees of € 0. So it is very unlikely that we will offer official support for proprietary operating systems. It is more likely that we offer small RISC-V runners or similar experiments. You can still bring your own runner, and we believe that having hosted GNU/Linux runners can already relieve projects. A project supporting three operating systems including GNU/Linux would currently need to host three runners. In the future, they can offload the maintenance of the GNU/Linux runner to Codeberg. If you consider that some jobs (such as linting and testing) might only need to run on one OS, you can spin up the proprietary OS runners less often, for example only during release preparations and the final build.

fnetX commented 2024年11月17日 17:08:38 +01:00

There is a runner up and running. But there is one issue that I do not yet know how to solve.

The runner registeres with labels "codeberg-tiny" and "codeberg-tiny-lazy". I expected it to only run jobs that specify the runs-on: accordingly.

However, it picks up jobs from repositories that don't set any runs-on. Previously, this works, because in the respective repositories there is only one runner (e.g. someone assigning one runner to their local repo, account or organization). But now, the Codeberg runner picks up these jobs.

I do not think that I can work around this easily. There are some issues with this:

• I do want people to explicitly opt-in to our hosted service, so that they check the rules first, it should not "magically work"
• it can conflict with and break existing setups, e.g. when the runner has special requirements and jobs suddenly run in Codeberg's runners and fail
• people might be confused about this behaviour or it might simply be unintended, e.g. because they assumed some jobs to run in a specially secured environment, and do not trust Codeberg enough to perform some actions

There is a runner up and running. But there is one issue that I do not yet know how to solve. The runner registeres with labels "codeberg-tiny" and "codeberg-tiny-lazy". I expected it to only run jobs that specify the `runs-on: ` accordingly. However, it picks up jobs from repositories that don't set any `runs-on`. Previously, this works, because in the respective repositories there is only one runner (e.g. someone assigning one runner to their local repo, account or organization). But now, the Codeberg runner picks up these jobs. I do not think that I can work around this easily. There are some issues with this: - I do want people to explicitly opt-in to our hosted service, so that they check the rules first, it should not "magically work" - it can conflict with and break existing setups, e.g. when the runner has special requirements and jobs suddenly run in Codeberg's runners and fail - people might be confused about this behaviour or it might simply be unintended, e.g. because they assumed some jobs to run in a specially secured environment, and do not trust Codeberg enough to perform some actions

fnetX commented 2024年11月19日 17:44:02 +01:00

The amount of jobs that is picked inadvertently is low enough. Another issue that I expected w.r.t timeout is probably not wasting resources, it's more of a display/update glitch: https://code.forgejo.org/forgejo/runner/issues/338

So I think this is ready to receive an alpha test drive by users. I propose the following rules for the codeberg-tiny runner:

• CPU: jobs should complete within 2 minutes on 2 CPU cores or within 1 minute on 4 CPU cores
• RAM: jobs should not require more than 2 Gigabytes of memory at peak times
• Overall/frequency: I hope users will do their best to save resources and not do unnecessary runs. We might specify more rules later. Since the runner currently picks jobs in order, please check that you don't jam the queue.
• Disk usage: Storing a lot of OCI images with little use is a waste of disk space. Doing a lot of environment preparation at the beginning of each image is a waste of resources, too. What about this:
  • Jobs can use any image of a predefined "allowlist" which we will specify. This list could contain things like ready-to-use images for static site generators, for example
  • jobs can use a custom image which is less than 100 MiB in size
  • jobs can run installation steps that result in a maximum of 20 MiB of network traffic and disk writes per run (e.g. the size of packages to install)

I think we should create a dedicated repository to list details and rules, as well as the rules for each image, allowing people to subscribe to important announcements and have general discussions about requirements and exceptions.

The amount of jobs that is picked inadvertently is low enough. Another issue that I expected w.r.t timeout is probably not wasting resources, it's more of a display/update glitch: https://code.forgejo.org/forgejo/runner/issues/338 So I think this is ready to receive an alpha test drive by users. I propose the following rules for the `codeberg-tiny` runner: - CPU: jobs should complete within 2 minutes on 2 CPU cores or within 1 minute on 4 CPU cores - RAM: jobs should not require more than 2 Gigabytes of memory at peak times - Overall/frequency: I hope users will do their best to save resources and not do unnecessary runs. We might specify more rules later. Since the runner currently picks jobs in order, please check that you don't jam the queue. - Disk usage: Storing a lot of OCI images with little use is a waste of disk space. Doing a lot of environment preparation at the beginning of each image is a waste of resources, too. What about this: - Jobs can use any image of a predefined "allowlist" which we will specify. This list could contain things like ready-to-use images for static site generators, for example - jobs can use a custom image which is less than 100 MiB in size - jobs can run installation steps that result in a maximum of 20 MiB of network traffic and disk writes per run (e.g. the size of packages to install) I think we should create a dedicated repository to list details and rules, as well as the rules for each image, allowing people to subscribe to important announcements and have general discussions about requirements and exceptions.

fnetX commented 2024年11月21日 19:03:20 +01:00

A summary is now available here and news will be posted there only: https://codeberg.org/actions/meta

This issue is mainly kept for visibility.

A summary is now available here and news will be posted there only: https://codeberg.org/actions/meta This issue is mainly kept for visibility.

Andre601 commented 2024年11月28日 17:40:01 +01:00

grafik

• Best goal I would like to reach is to re-implement my GitHub Action Workflow that builds a resource and publishes it to the Repository's release + external site. Tho, this relies on the question on how much the action used there is reliant on GitHub-exclusive API (i.e. if it uses graphql) and if there is a way for forgejo to "mimic" GitHub REST API.
• The above mentioned job would probs require a bit of resources due to the downloading of dependencies and building of the final file (Java jar files).
• I preferably would want to use caching for the dependencies used for building the files, as it A) reduces bandwidth usage on your end and B) speeds up builds by eliminating the downloads. This is a current issue I face in Woodpecker.
• In best scenarions maybe 1 a month at most, tho I may have more if bug-fixes are needed to be made.
• I could wait for a while honestly. The releases usually aren't high priority in any way.

These would be my answers for a future goal. However, right now would I give these answers instead:

• Use for page building and also page-previews (Effectively the same, but on a different target repository)
• Very low resources, as page build would be relatively low in consumption (Uses Python and MkDocs, which from my experience is fast and low on resources)
• Would use caching for downloaded dependencies.
• Depends on factors such as updates to dependencies. These updates would then usually also create page previews. In the end, it depends on how many edits I would make to pages and how many dependency updates there would be, but a rough estimate would be like once a week on average?
• Preferably not that long, as I would want page updates to be available as soon as it would be possible.

Really hope this answers the questions properly...
Right now do I have questions of my own, namely how a final action could look like for my use-cases of building a page and making page-previews...
From what I can gather would I need these separate steps:

• Checkout source and target repository
• Install Python
• Install dependencies
• Build page
• Commit and Push changes to target repository
• (For previews): Comment on PR with the outcome

Regarding the comment would there also be a similar question to what I had at the start. Namely, how easy or difficult it would be to use a GitHub Action for commenting, as it would allow me to re-use a comment instead of posting new ones each time, spamming if there are multiple updates.

I hope this comment makes any sense... Because even I have a hard time writing it in a way that hopefully makes sense. 😅

 - Best goal I would like to reach is to re-implement my GitHub Action Workflow that builds a resource and publishes it to the Repository's release + external site. Tho, this relies on the question on how much the action used there is reliant on GitHub-exclusive API (i.e. if it uses graphql) and if there is a way for forgejo to "mimic" GitHub REST API. - The above mentioned job would probs require a bit of resources due to the downloading of dependencies and building of the final file (Java jar files). - I preferably would want to use caching for the dependencies used for building the files, as it A) reduces bandwidth usage on your end and B) speeds up builds by eliminating the downloads. This is a current issue I face in Woodpecker. - In best scenarions maybe 1 a month at most, tho I may have more if bug-fixes are needed to be made. - I could wait for a while honestly. The releases usually aren't high priority in any way. These would be my answers for a *future* goal. However, *right now* would I give these answers instead: - Use for page building and also page-previews (Effectively the same, but on a different target repository) - Very low resources, as page build would be relatively low in consumption (Uses Python and MkDocs, which from my experience is fast and low on resources) - Would use caching for downloaded dependencies. - Depends on factors such as updates to dependencies. These updates would then usually also create page previews. In the end, it depends on how many edits I would make to pages and how many dependency updates there would be, but a rough estimate would be like once a week on average? - Preferably not that long, as I would want page updates to be available as soon as it would be possible. Really hope this answers the questions properly... Right now do I have questions of my own, namely how a final action could look like for my use-cases of building a page and making page-previews... From what I can gather would I need these separate steps: - Checkout source and target repository - Install Python - Install dependencies - Build page - Commit and Push changes to target repository - (For previews): Comment on PR with the outcome Regarding the comment would there also be a similar question to what I had at the start. Namely, how easy or difficult it would be to use a GitHub Action for commenting, as it would allow me to re-use a comment instead of posting new ones each time, spamming if there are multiple updates. I hope this comment makes any sense... Because even I have a hard time writing it in a way that hopefully makes sense. 😅

lslalbai commented 2024年12月23日 21:20:48 +01:00

I'd like to use this to automatically publish Composer packages when a triggering tag is pushed. Right now I'm getting reqPackageAccess when attempting to use the Forgejo action to publish the package archive file.

I'd like to use this to automatically publish Composer packages when a triggering tag is pushed. Right now I'm getting `reqPackageAccess` when attempting to use the Forgejo action to publish the package archive file.

fnetX commented 2025年07月16日 16:40:52 +02:00

https://codeberg.org/actions/meta/ is now the canonical place to learn about our hosted Forgejo Actions.

https://codeberg.org/actions/meta/ is now the canonical place to learn about our hosted Forgejo Actions.