Thank you for all your kind emails. It is, as always, a pleasure to contribute to Racket.
I spent some time discussing this Sam today which mentioned GitHub Actions. I had actually been part of GitHub Actions Beta and dismissed it straight away because initially they were not supporting self-hosted runners and there weren't many details on how free was the offer for public repos. Sam's point made me revisit the current status of GitHub Actions CI which just recently left Beta. It turns out, there are quite a few changes. A lot of the information I picked up comes from these references: https://www.youtube.com/watch?v=9EoNqyxtSRM https://help.github.com/en/actions/automating-your-workflow-with-github-actions/about-self-hosted-runners https://github.com/features/actions https://twitter.com/pocmatos/status/1195100718270681088 My understand stands as follows: - GitHub Actions provides CI free of charge (unlimited minutes) on public repositories on a variety of operating systems (Linux, Windows and MacOS) on x86_64; - GitHub Actions provides a self-hosted runner that runs on X86_64 and ARM devices; - GitHub Actions is highly integrated, as expected, in the workflow and uses as other services do, a yaml configuration file. - Pietro Albini, working on porting the Rust CI from Azure Pipelines to Github Actions mentioned that Azure and Actions are very similar. This is certainly a compelling argument towards using GitHub Actions. Also, we wouldn't have to pull from Python code for CI (which we would if we used Buildbot). As mentioned GitHub Actions are part of GitHub and very well integrated with the workflow. On one hand a part of me worries about vendor lockin with GitHub, but then again we are already so invested in GitHub that adding CI to the mix won't (I think) worsen the situation. There's however, the issue of supporting more architectures than GitHub Actions provides. My suggestion comes from my own experience with QEmu and what Rust is also doing. Lets come up with support tiers. We can have a tier where we compile, test and benchmark and other tiers where we only ensure Racket builds (for example with Rust, see https://forge.rust-lang.org/infra/docs/rustc-ci.html). We can certainly use GitHub Actions hosting to test on x86_64 on all supported OSes. We can then use my own CI server as well (to compile natively but also run cross-compilations and emulated testruns) and the self-hosted runner on my ARM boards. For architectures that are not supported by the github runner, we can cross compile. For those architectures for which I have boards, we can weekly (for example) run some scripts that compile and test natively (for example mipsel and riscv64). In the long run, as initially mentioned, the idea is to gather the information in a racket webapp dashboard (I discussed this briefly today with Jack Firth, who actually works in this area, and we will be discussing the architecture of this dashboard and integration with the CI system in the coming week). With a setup like this, there are few compelling reasons to design a system from scratch using Buildbot, so I am sold on the idea of moving forward with Actions. It is actually a good time. Next week, for family reasons, I will have extra free time on my hands and I am sure I can bring this proposal up to speed and have some more information towards the end of next week. What are everyone's thoughts? If nobody complains loudly, I will follow through and bring up a draft PR, with a Github Actions CI system during next week. Kind regards, -- Paulo Matos -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/87a78x5b28.fsf%40linki.tools.
