underlap

Return to GitHub

“As a dog returns to its vomit, so fools repeat their folly.” – Proverbs 26v11

After developing ipc-channel-mux on Codeberg, I wanted to enable CI.

Why develop on codeberg?

I prefer Codeberg to GitHub because of the likelihood that code on GitHub will be used to train AI code assistants, to which I object on environmental, licensing, and technical grounds. I also like the fact Codeberg is a non-profit organisation.

macOS and Windows

CI on macOS would be useful as I recently got all the tests passing on Linux and published the crate, only to find some of the tests failed on macOS.

CI on Windows is essential as I don’t have a Windows machine and I don’t particularly want to boot up a Windows VM regularly and remember to re-run the tests there.

Anyway, I started looking into the docs for Woodpecker CI on Codeberg only to find that all the CI jobs run in containers. I dutifully raised feature requests for Windows support and macOS support, but the feedback wasn’t optimistic about them being implemented, mainly for cost reasons.

So what other options were there for macOS and Windows CI?

Self-hosting CI runners on macOS and Windows would require me to run macOS and Windows in a hosted environment, locally, or in a VM. I didn’t want to incur the cost and pain of this option.

So, the least worst option seemed to be to move the repository to GitHub.[1]

Another option was to mirror the repository from Codeberg to GitHub and run CI there. But this wouldn’t be particularly usable if and when other developers get involved via GitHub (surely a necessary step towards supporting Servo).

There were some other advantages of moving to GitHub: ipc-channel-mux would then be hosted on the same platform as ipc-channel and issues would be easier to cross-reference.

Another disadvantage of mirroring was that CI configuration is usually checked in to the repo to be tested. So once I decided to run CI on GitHub, the repo was going to be biased toward GitHub.[2]

Developing for proprietary platforms

When I consider that macOS and Windows are proprietary platforms, it seems more reasonable to use a proprietary system to host the code and provide CI. At least that’s my post-justification.

What else is there to say? A couple of things it turns out.

Opting out of AI training

The cleanest way to opt out of AI training on GitHub would be to use non-permissive licensing, but since I would like ipc-channel-mux to be used alongside ipc-channel, it should have the same, permissive license.

Engineering benefits

When I switched to GitHub and copied the CI configuration from ipc-channel, several benefits accrued:

Conclusion

In spite of my misgivings about GitHub, moving back there definitely makes sense technically, if not ethically. I’ll have to live with that.

  1. Other proprietary options, such as GitLab, were available, but since the Servo project, including ipc-channel, is on GitHub, that’s the natural choice. ↩︎

  2. This feels analogous to editor configuration: checking in editor config files is generally frowned upon because it biases the repo towards particular editors. Also, such configuration is essentially unrelated to the repository code and is a bit of a distraction. But it makes sense to maintain repository code and CI jobs together, so there we are. ↩︎