What about #CI on #Codeberg?

We are providing access to our #WoodpeckerCI instance to those who need it, some caveats still apply.

Also, you can read about the upcoming #ForgejoActions.

Check out our docs to learn more about the state of CI on Codeberg: https://docs.codeberg.org/ci/

Working with Codeberg's CI | Codeberg Documentation

@Codeberg this is great, is there any plan to support non linux OS? I need to test my softwares on linux but also on various BSDs
@Codeberg Forgejo Actions are new! What’s that? Smt equivalent to GitHub Actions, or it’s more of a Lambda-like Functions service?

@Codeberg Oddly enough https://forgejo.org/docs/next/admin/actions/ says that the following endpoints are available:

[...]
- in /user/settings/actions/runners to gain access to all repositories of the logged in user
- in /{owner}/{repository}/settings/actions/runners to gain access to a single repository.
But, neither of them exists:
However, I was able to find:
/{user}/{repo}/settings/runners,
but there appears to be no option to add runners on a for-all-user-repos. (Although it is possible on a for-all-organisation-repos)

Forgejo Actions administrator guide | Forgejo – Beyond coding. We forge.

@Codeberg Woodpecker has been working great for me!
@daviwil thoughts on it vs SrcHut?
@fosskers, chiming in even though it's directed at @daviwil. I use the sourcehut ci to build and deploy my Hugo (plus ox-hugo/emacs org format) based website, so it's a pretty simple use case. But I really like how integrated and straightforward it is. Also love how the remote build session stays alive if the pipeline fails and you can easily ssh into it to investigate what happened and try fixes.
@fosskers You mean just as a CI system? I haven't used Sourcehut Build in a while, but it was pretty easy. Woodpecker is nice because you can use arbitrary Docker containers from Docker Hub to run your CI steps. Easier to create your own custom images that have all dependencies ready so that the job runs super fast.
@daviwil @fosskers i like builds.sr.ht because its just my normal workflow + a ~10 line yaml file

@rml @fosskers Woodpecker would also fit that definition. Here's how I auto-publish websites generated with `org-publish`:

https://codeberg.org/SystemCrafters/systemcrafters-site/src/branch/master/.woodpecker.yml

Most of the lines here are just `git` incantations.

Another example of building a CMake project:

https://codeberg.org/mesche/mesche/src/commit/f236a73cd80a39ba9c42f19f9f83a0b5bef3554c/.woodpecker.yml#L1-L8

Using a pre-configured Docker image with GCC and CMake already set up makes it a lot simpler.

systemcrafters-site

The official System Crafters website!

Codeberg.org
@daviwil @fosskers this is the thing, I love #srht but lack of org support is a major hassel

@rml Codeberg supports Org file preview well enough, but they use a Go-based HTML exporter so it's a little janky and inaccurate. Better than nothing, though!

@fosskers

@daviwil @fosskers i don't need much tbh, and i assume its better than pandoc org->md, which is what i use with sr.ht (probably to my disadvantage)
@Codeberg what are the advantages of Actions over Woodpecker? and why adapt to GitHub's syntax, is it an industry standard?

@Codeberg
İs it okay to use ci for building and deploying websites to pages.

is it okay to use on unpopuler projects ci pipeline?

Also is it okay to run small ci jobs daily to update metadata repo(like fetching some files and writing their hashes to repo)

(Sory if sounded rude i am not a native nor a good speaker)