Just a brief summary about CI. I have been looking at CI using GitHub Actions since yesterday and although there are a few rough edges with the workflow at the moment due to limitations in the syntax and interactions between different parts of the system, it looks like we can build a pretty decent system in the long run. Even better after they release the github runner for more architectures and we can self host these.
On the downsides that I faced are interactions between environment variables and paths in the yaml file. For example, it’s unclear on which path you start at on the different OSs and only through experimentations with OS you get to find out. Say you put that path in an environment variable. Unfortunately, you can’ use it outside a shell because working-directory keywords and path keywords` in upload and download artifacts won’t expand environment variables, so you have to hard code these, preferably relative paths.
github.community has been very helpful. Github staff are actually working overtime to answer questions there about github actions so that’s a plus.
A big issue was for example, to define an environment variable in a step insdie a job that can be used by other steps. Unfortunately there’s no obvious way to do that because each job starts a shell. Online some staff member pointed to this document : https://help.github.com/en/actions/automating-your-workflow-with-github-actions/development-tools-for-github-actions#set-an-environment-variable-set-env
which shows a way to do it with echo "::set-env name:: ..." syntax
I have created this: https://github.com/LinkiTools/racket/blob/pmatos-gha-ci/.github/workflows/ci.yml
with results here:
Unfortunately macOS is failing build CGC. I might be doing something unsupported since it’s the first time using macOS (and don’t have access to one).
If anyone here has access to a macOS, could you please check if I have made a mistake while configuring the racket build?
Myself and @notjack have a CI related meeting on Thursday 8am (Berlin time) - same as Wednesday 11pm (San Francisco time). @notjack has a lot of experience with building complex CI systems so I wanted to draw some of that experience onto Racket as I would like, once the CI system with GHA is complete, to develop a Racket Web Visualization Dashboard for the CI. Which means putting together a database that’s written to by the actions and a dashboard that reads from the database and present the most relevant information to the user as a timeline. We can have through CI quite a good commit per commit view of the world as it is but without a dashboard it’s hard to understand the global picture. Has Racket been improving it’s memory usage, or performance. Or how’s typed racket been improving over time? Or what’s the penalty that we are still suffering from using CS compared to 3m, etc.
Happy to have others join the meeting if they are interested.
In any case, i will write a summary of the meeting afterwards.
Looking forward to it!
I mentioned some stumbling blocks with GHA but I feel like I should mention the pros as well. For one, I can see this marketplace for user defined actions to become really big doing all sorts of interesting stuff.
@notjack woot? by my calculations, you’re having some pretty bad insomnia.
Yup. Though I went to sleep early then woke back up.
:shrug:
Brains are weird
Also, github actions is a larger puzzle where ci is just a small piece. We can start having workflows for first time contributors, bug triaging, etc and all of that integrating with CI. This level of integration would be hard on any other system.
The current actions system only provides 2-core systems with some gigs of memory and I haven’t ran into troubles yet but I have installed (but not yet enabled) the runner on my larger server, so that could be enabled for larger workloads. Or for example, to get CI from PRs done quicker. Contributors shouldn’t need to wait 2 hours to get a CI tick. I think they should be free to open draft PRs and use our infra to check that their future contribution actually works and get a quick turnaround so that they don’t get disengaged.
Sorry for the wall of text - I have a few other things to point out but I will get there later on.
Thank you for looking into this so thoroughly
I would join the meeting but 2 am Bloomington time is not going to work for me ;)
You are 3 hours ahead of San Francisco?
yes (eastern time in the US)
I share @samth’s time zone. My background in web portals can serve the dashboard effort. Will attend the meeting.
My other thought is that we should merge something that uses GitHub Actions ASAP, so that we can all start getting experience with it.
Sure - pushing a PR before heading off to bed.
I had to disable mac (catalina) building/testing for now because it crashes during install of cgc. I mentioned this to Matthew who thought it could be due to --enable-cify but I tested and it is not. Matthew tested it in a non-catalina macos but couldn’t reproduce. I have no access to mac machines so can’t repro it - can only see it in ci. macstadium which is where github gets its mac machines doesn’t offer pay per hour rentals - only monthly subscription unfortunately.
I checked a timezone calendar and the only way for all of us to join a meeting together would be to have it during work hours. That wouldn’t be a problem for me though.
I’m open to moving the meeting time we picked if that makes it easier for more people to join
I’m on a sabbatical. I am most likely open.