CI/CD

As CodeFloe has a strong focus on automation of any sort itself, providing sophisticated CI/CD solutions to its users is a must.

CodeFloe does not offer just a single CI/CD solution (which for other services is usually bound to their platform exclusively), but two services, of which one is even forge-agnostic, i.e. it can be connected to other Git forges without the need to change workflows.

It is up to you which one to choose. Crow CI is an independent, centrally administrated CI/CD solution. It is developed and maintained by the people driving CodeFloe. Forgejo Actions is integrated into the platform and configured on a per-repo basis, following and reusing the same approach of GitHub Actions.

Both have fundamental design differences: while Crow CI comes with a UI that integrates all settings and repos into a single dashboard, Forgejo Actions is directly integrated into the Forgejo UI and only has a minimal UI to view workflow logs.

Forgejo Actions relies heavily on the use of predefined actions (aiming to simplify repetitive tasks), which require a full NodeJS runtime. This is also the reason why every build environment that should support the use of "actions" is based on a node image. Crow supports "plugins" which are similar to "actions". These can be written in any language as long as they are called through an (immutable) entrypoint in a container image.

Crow CI

Crow CI is a FOSS CI/CD app written in Go. It is a fork of Woodpecker CI and developed/maintained by the CodeFloe team. If you have a CodeFloe account, you can login to ci.codefloe.com and activate the repos you have write access to.

If you encounter usage issues and/or have feature requests, issue them directly in the Crow CI repository.¹

Forgejo Actions

Overview

Forgejo Actions is developed by the Forgejo team. It allows GitHub-actions based workflows and is directly integrated into Forgejo, the software powering CodeFloe.

To run an action, you need to delegate it to an available runner. All runner have labels set which can be referenced in the runs-on field. All available labels are listed at https://codefloe.com/user/settings/actions/runners (Login required). Some labels reference multiple runners while others reference a single runner. The names aim to describe the underlying environment in a descriptive manner.

Tip

For container/docker actions, use the docker label. This will create an environment where you can talk to a Docker daemon running via dind.

An example workflow could look like this:

name: hello-world

on:
  push:
  workflow_dispatch:

jobs:
  hello-world:
    runs-on: debian-latest
    defaults:
      run:
        shell: sh
    steps:
      - name: hello-world
        run: |
          echo "Hello, World!"
          sleep 30

Important

The common windows-latest and macos-latest labels from GitHub Actions are not supported. This is simply due to the fact that Forgejo runner does not run on these platforms (yet).

As all Actions are by default written in JavaScript, the base image that all jobs run within must support NodeJS. You can use an arbitrary image without node if you are not planning to use any predefined actions.

Note

ubuntu-latest is in fact running on Debian and is equal to debian-latest. There is no official Ubuntu NodeJS image and Debian and Ubuntu are largely compatible. This was mainly done to simplify migration from GitHub Actions.

Custom Containers

All jobs run within containers. The runs-on: key specifies a compatible NodeJS image (either LTS or latest) which is able to execute Actions. You can also use the containers: key to specify an arbitrary container image for a job of yours. Note that when doing so, Actions are not supported if this image does not have NodeJS installed.

name: hello-world

on:
  push:
  workflow_dispatch:

jobs:
  hello-world:
    runs-on: debian-latest
    container:
      image: library/alpine:latest
    defaults:
      run:
        shell: sh
    steps:
      - name: hello-world
        run: |
          echo "Hello, World!"
          sleep 30

If you encounter usage issues and/or have feature requests regarding Actions itself, please report them directly in the respective Forgejo repository. If you instead face any issues using Actions on CodeFloe, you are welcome to open a thread in our Forum.

Examples

The following two repositories show exemplary workflow definitions for both Crow CI and Forgejo Actions:

Contributions welcome!

Other external example repositories can be found here:

gitea/awesome-gitea: "Actions" section from the "awesome-gitea" repository.
Codeberg-CI/examples: Collection of language-specific workflows for Crow CI (= Woodpecker)
Delightful Forgejo: Delightful Forgejo Actions list

If you are aware of others which should be added here, please file a Pull Request!

Capabilities

As the hosted runners are open to everyone and run in a semi-public context, the security settings must be "relatively strict". This means that certain features, such as running containers as privileged or mounting external volumes, are not available.²

Hardware

CodeFloe provides the following servers to process CI/CD jobs:

Name	Total CPU	Total Memory	Architecture	Job Capacity	CPU/Workflow	Mem/Workflow
artemis	16	64	amd64	10	4	3
hades	12	64	arm64	4	2	3
demeter	12	64	arm64	4	2	3
minerva	11	64	arm64	4	2	3
gaia	10	32	arm64	5	4	3
ci-arm1	8	16	arm64	4	2	3

The total job capacity of all runners is split 50/50 between Crow CI and Forgejo Actions.

Note

There is currently no limit in place for the overall amount of (parallel) builds per user or the build duration per user/org. Such will be added in the future.

In the meantime, we appeal to users to be mindful of their usage and avoid excessive resource consumption. Excessive usage or abuse will be detected and addressed.

Adding your own agent/runner

Crow CI

Follow the documented process to add a new "public" runner from the Crow CI docs.

Use the following settings in the agent config:

CROW_SERVER: ci.codefloe.com
CROW_GRPC_ADDR: grpc.ci.codefloe.com

You can set additional CROW_AGENT_LABELS. By default, the agent will be restricted to the Crow org_id for which you created the agent token in the Crow UI.

Danger

It is not possible to configure an agent to process builds of multiple users/organizations. You need to add multiple agents to achieve this.

Tip

When you starting processing builds on your own agent(s), you might run into rate-limiting (429 http errors) soon. To avoid this, please open a PR add the IPs of your agents to the fail2ban playbook of CodeFloe's infra configuration following the existing entries.

Actions

There's an existing guide in the Codeberg Documentation which can be followed to add a self-hosted runner for Actions. Make sure to use https://codefloe.com as the argument for the --instance flag.

Tip

Besides the deployment methods listed in Codeberg's documentation, there is also an Ansible role forgejo_runner in the devxy.cicd collection, which is used to deploy the hosted runner on CodeFloe.

If you wonder why Crow CI is hosted on Codeberg and not on CodeFloe: when starting out, the Crow CI org was created on Codeberg. CodeFloe did not yet exist at the time. Crow CI might be migrated to CodeFloe in the future. ↩
Theoretically, it is possible to do so when you attached your own runners. However, the flexibility of detecting this must first be added to the respective services. Right now, there is no way to allow it only for certain agents. ↩