@Suiseiseki Sadly this didn't figure into the equation.

@categulario At this point it's irrelevant. It's either GitHub or just throw up a tarball on my site. I couldn't care less.

@jakob @codeberg @jens @adam Thank you for this update.

@jakob @codeberg @jens @craigmaloney

Is there any plan to integrate CI/CD into Gitea?

All I found was a thread from 2019 saying that it's desired, but the only solution was to have the CI system be entirely separate from everything else (git hosting, issue tracking, etc.)

https://discourse.gitea.io/t/continuous-integration-ci-continuous-delivery-cd/1639/8

@adam @jakob @codeberg @craigmaloney IMHO superfluous, but YMMV. It's integrated enough for my needs.

What are you missing?

@jens @jakob @codeberg @craigmaloney

I can't find any CI/CD features in Gitea (documentation, demo instance, etc). I'd want automated tests to be run on each check in, in a clean environment. For example: https://salsa.debian.org/adam_hax/pam-u2f/-/pipelines

For example, some projects prevent merging if the CI/CD tests don't pass. Even when projects are not that strict, it's nice to have the results are right there on the merge request page.

Plus it looks like Drone CI can't read .gitlab-ci.yaml files, which means rework

@adam @jakob @codeberg @craigmaloney Yes, it means rework, but these features work, if I recall correctly.

@jens @adam @jakob @codeberg @craigmaloney I will just say that self-hosting a Gitlab instance is also a possible solution. Plus, independent Gitlab instances like https://0xacab.org/ exist and do a good job.

@jens @adam @jakob @codeberg @craigmaloney

There is a #CI at #Codeberg but it is not yet turned in a standard service.

See: https://codeberg.org/Codeberg-CI

CI is based on #WoodpeckerCI a #FOSS fork of #Drone

@humanetech

I wish Codeberg success.

@jens @adam @jakob @codeberg @craigmaloney

@adam Gitea works with Woodpecker-CI. Maybe this is what you are looking for: https://woodpecker-ci.org/docs/administration/forges/gitea @jens @jakob @codeberg @craigmaloney

@adam @jens @jakob @codeberg @craigmaloney You don't need a CI/CD within Gitea to achieve that. Gitea can call a webhook to start a CI run, and Gitea has APIs that let the CI report its status back to Gitea, bound to a given SHA.

So you can have build results on PRs, even multiple statuses, just like on GitHub. You're not tied to any single CI/CD either, and you can use more than one.

It's lovely, and works just fine right now. It only requires a Gitea-aware CI, and there's a few of those.