Great work on this @samth. Thanks. I have been set back yesterday since I issued by mistake rm -rf ~ … i know… embarassing. Only noticed 5 secs later when it was taking too long. Still picking up the pieces of what’s left.

:disappointed:

Oh no

I know… well, first thing my wife said is that she’ll be shredding my univ. diploma. :rolling_on_the_floor_laughing: At least someone’s still funny around here.

At the same time, most of my serious work stuff is on github these days so nothing serious is lost

The biggest annoyance today was losing my ssh and gpg keys…

Trying to get everything reset.

Back to thinking about CI… the tests for Chez are quite errr… underwhelming. Any suggestions on how to best test the Chez component standalone?

what do you mean by underwhelming? Is it running the full Chez test suite?

maybe I missed something…

https://github.com/racket/ChezScheme/blob/master/.github/scripts/test.sh

are the runmats calls here the ‘full chez testsuite’?

I think so

I think make test is what’s advised in the README

I will have to take a deeper look but it ran so quickly that I couldn’t believe that would have been a thorough testsuite.

Not sure what happens here: https://github.com/racket/racket/runs/626819277

even downloading the logs produces nothing

Something is going on, on the GitHub runner side.

I am going to try to allocate a couple of machines to run these on dedicated hardware.

Oh… Github status says actions were pretty unstable today so that should explain the issue above.

fun fact: there used to be a systemd problem where it would automatically mount your hardware’s EPROM as a read-write directory, so if you did rm -rf / it would erase your firmware and permanently brick your computer