Consider switching CI to GitHub actions

[twizmwazin]

• [x] Did you check to see if this issue already exists?
• [x] Is this only a single feature request? Do not put multiple feature requests in one issue.
• [x] Is this a question or discussion? Don't use this, use https://lemmy.ml/c/jerboa

Describe the feature request below

Using GitHub actions for Jerboa's CI would introduce a number of advantages:

• Reliability issues would be effectively eliminated. I have used Github actions professionally for over a year now and never once has a GitHub-hosted build failed to start due to server availability issues.
• No sysadmining. Time spent sysadmining the CI is time not spent on something better. I know the main Lemmy folks have been quite busy the last few weeks.
• It allows contributors to run the CI on branches of their own fork. The current woodpecker system is tied to the main repo and users do not have any way to use it other than making a PR and hoping that it picks up the job, or trying to stand up their own copy on their own server.
• It is integrated with Github's UI. This one isn't that big of a deal, but it is more familiar to users since it is widely adopted and served from the same site they make issues and PRs on.
• It is integrated with Github's permission system, enabling collaborators to easily restart jobs if needed.
• Very easy to set up any GitHub-based automation, including releases (#797). Pass the GitHub api token to a step and use the gh cli to interact with just about anything on GitHub.
• It is free (as in beer). Github gives any open source project unlimited minutes with their standard runners and up to 10 jobs can run at a time.
• Huge community with lots of resources available.

There are a few downsides, though in my personal opinion they are minor:

• While much of the software is open source, including the self-hosted runner, the backend that runs on Github's infrastructure is not.
• If you release builds from a Github-hosted runner, they'll have access to your signing key. This can be mitigated however on a self-hosted runner, such that your signing key is kept local and all network traffic can be audited. A typical CI build would require no secrets of any kind.

[itsmegb]

A note to add on this, @dessalines mentioned a reluctance to switch to GH actions as the project may eventually move off of GH.

Gitea are currently working on Gitea Actions which aims to be a GH Actions compatible CI/CD pipeline for Gitea.

https://docs.gitea.com/next/usage/actions/overview

Just thought it was worth mentioning.

[twizmwazin]

I personally think switching off of GitHub would be a significant mistake. I understand the concerns about avoiding big tech and wanting to decentralize, which is part of the entire spirit of projects like this. However, it also significantly reduces visibility of the project and imposes a barrier for newcomers to contribute. This project has taken off over the last couple of weeks with dozens of contributors, and I am confident in saying that if the project was hosted anywhere else, many of those people wouldn't have bothered if they had to register and set up an account there. GitHub makes open source accessible, regardless of feelings about their ownership and governance.

[dessalines]

We were also asked to switch away from the WoodpeckerCI we use on lemmy (and all its associated projects), to github actions.

Pros of woodpecker

• Fully open source, including the spec.
• Self-hostable
• Fully portable, can work with any git source repo we choose.
• Development out in the open.
• The woodpecker devs are very responsive, and have even contributed to lemmy's CI.
• Can run as many agents / runners as you want. (currently we have 4, but could probably use more).

Cons of woodpecker

• Not yet 1.0 stable (although most of those problems have gone away now that I've switched it to another server).
• Sometimes picks up older builds (which may be github's fault), which then need to be restarted manually.

Pros of github CI

• They run jobs for you.
• A lot of people use it and are familiar with it.

Cons of github

• Closed source.
• Vendor-lock in. At any moment, they could start charging for it, or restricting it. This happened to us with drone-ci, which woodpecker is a community hard-fork of.
  • The fiasco with reddit closing off their API and charging for it, is equally possible with github. People spent thousands of hours building reddit apps that will soon be useless. Lets not make that same mistake by writing jobs for a closed-source CI.
• They get all your secrets, which are necessary for many of our deploys, such as lemmy-js-client, joinlemmy-site, and lemmy. Jerboa could also potentially do deploys from CI, and I wouldn't want to give github all my secrets.
• Its more work, not less, for us to switch our CI system to a proprietary one in the middle of development.

---

Switching away from github is more of a "when", not an "if" scenario. When federated issue trackers become mature, we, likely along with most projects, will switch away from github. When that happens, I'll be glad we didn't tie ourselves to github's proprietary CI.

If woodpecker CI is missing features, then let's support it by adding those. It is a fully open source project unlike github, so you can actually improve it with features you'd like to see.

[twizmwazin]

Regarding the cons of Github CI:

Vendor-lock in. At any moment, they could start charging for it, or restricting it. This happened to us with drone-ci, which woodpecker is a community hard-fork of.

This isn't a concern in my opinion. While yes, I agree that Github could at any point change their policies and effectively force a migration away, CI infrastructure can be designed in such a way that this is trivial.

• Github actions supports running your CI in a docker container. The docker engine is itself is open source, and many other CI systems, including fully-open ones, support running docker containers. In the event that we have to migrate away, we would be able to keep our runtime environment.
• While github actions has a large collection of pre-made actions that are not portable, you can also just run inline shell commands or shell scripts in the environment, which is nearly universally supported across CI systems.

Given those two points, a pipeline that consists of a custom docker image and a script that is executed in that environment can be easily ported to most CI infrastructure. At that point, Github is only providing infrastructure, and porting to a new system would be trivial. We wouldn't be meaningfully tied in at all.

---

They get all your secrets, which are necessary for many of our deploys, such as lemmy-js-client, joinlemmy-site, and lemmy. Jerboa could also potentially do deploys from CI, and I wouldn't want to give github all my secrets.

See my point above about self-hosted runners for this specific scenario. We also don't have to switch everything to github actions, either. It would be very reasonable to do pull request CI, which requires nothing secret, on github CI, and then continue using another fully self-hosted solution like woodpecker for releases. This would alleviate the usability and performance issues that make everyday development hard while not giving Github anything, or risking github having access to secrets.

---

Its more work, not less, for us to switch our CI system to a proprietary one in the middle of development.

As someone pointed out on Element, someone already has a fork where they have done this for us that we could merge in. If their implementation is not good enough, I and others have volunteered to take this on. I do this professionally for my day job, and am more than capable of doing the transition.

---

When federated issue trackers become mature, we, likely along with most projects, will switch away from github.

I love the optimism, but I think this is incredibly unlikely. Maybe the die-hard free software community will migrate away, but based on existing trends in software most people are going to prefer pragmatism and convenience over ideology and use whatever is free and readily available.