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 <sa...@cs.indiana.edu> 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 <jackhfi...@gmail.com> 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 racket-dev+unsubscr...@googlegroups.com. > > 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 racket-dev+unsubscr...@googlegroups.com. > 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 racket-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAH3z3gammsbDmDATDF4wbgvHbAb2V20NL5m80H_atSUOFs-87A%40mail.gmail.com.
