I'm relatively in favor of a GitHub Actions based approach. I was also in the beta and wrote an action <https://github.com/jackfirth/racket-package-ci-action> for building and testing Racket packages. I would be happy to help with this effort, especially the Docker-based parts of implementing an action.
On Friday, November 15, 2019 at 9:01:12 AM UTC-8, Paulo Matos wrote: > > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/6a1ef4d3-5eeb-4b51-80aa-ad359084cffb%40googlegroups.com.
