While it's about CI of Racket programs rather than of Racket itself, I wanted to point to a recent discussion on Greg Hendershott's "travis-racket" repository: https://github.com/greghendershott/travis-racket/issues/37 I think it's a very important piece of tooling for the Racket environment, and, given that it's used in `raco pkg new`, I think it's worth considering a quasi-official piece of infrastructure.
In particular, based on my quick-and-dirty work on a sort of port of the repository to AppVeyor (to test Windows-specific issues), I agree with this comment of Greg's <https://github.com/greghendershott/travis-racket/issues/37#issuecomment-538756030> : One quick thought: Much of what install-racket.sh does is fill a void -- > the absence of a redirect server with logical URLs, which the core Racket > team has so far been unwilling or unable to provide themselves. > > That is, something like > download.racket-lang.org/{version}/{platform}/{flavor like minimal} would > redirect to NEU or NW or wherever. > > - If the core team releases a new version, they add it. > - If the core team is having a server issue (e.g. "Winooski"), they > just change the redirect. > > As opposed to: > > - Having a redirect server in the form of a big case statement in > install-racket.sh. > - Someone like you or me having to notice and eventually update it > days or weeks later. > > Maybe after such a change install-racket.sh and this repo still exist in a > simplified form, or not, I don't know. > (I'm posting here instead of on Slack for persistence.) -Philip On Mon, Nov 18, 2019 at 11:55 AM Sam Tobin-Hochstadt <[email protected]> wrote: > This sounds great. I see also that Bogdan has developed an action for > downloading Racket. > > Let's continue this work by organizing in the #ci channel on Slack, > which I've just created. Anyone else who's interested should join that > channel, and we'll work out next steps there. > > Sam > > > On Sat, Nov 16, 2019 at 2:50 AM Jack Firth <[email protected]> wrote: > > > > I'm relatively in favor of a GitHub Actions based approach. I was also > in the beta and wrote an 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 > . > > -- > 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/CAK%3DHD%2BYQmN%3DXPnRoAXad1QuoiSmb%3DA1o5RWeU3Yo0A0B%2BQiV_A%40mail.gmail.com > . > -- 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/CAH3z3gammsbDmDATDF4wbgvHbAb2V20NL5m80H_atSUOFs-87A%40mail.gmail.com.
