How are you getting CI noise? Cause I don’t get any… I have to check the CI page myself and I have lately been doing a poor job on that. :disappointed:

I would wish to get an email for each failed workflow.

And yes, there’s a lot of flakiness sometimes on github. Like a network failure or some job is just cancelled…

Would need to thing about what’s going on and what can be done to solve it.

Like, this recent one: https://github.com/racket/racket/runs/3139518930?check_suite_focus=true#step:9:803

Why would these tests take 6 hours? then of course, end up being cancelled.

Or this: https://github.com/racket/racket/runs/3138600414#step:8:13

Then we have some flakiness on portlib: https://github.com/racket/racket/runs/3139182931#step:9:68

Maybe github is throttling us and we need to simplify the amount of jobs we submit.

For example, with CS being in production now for a while I am not sure it’s work testing so many combinations of BC.

Maybe we should drop most of them and build 1 type of BC or something.

I think pushers get notification, right?

But yeah, I totally agree that if we can’t deal with flakiness, we should not test as much. It does more harm (from the noise) than good.

I get a notification for every failed CI run (which is a lot). I also get notifications from DrDr and snapshot builds and the Racket service monitor. Also: every time Apple notarizes a build — which is especially annoying and useless, but there’s apparently no way to turn that one off.

Running a lot fewer BC builds seems like a good idea.

I think you can turn off the CI failure emails. I’ve done that, I think

Yeah, in https://github.com/settings/notifications there’s an “actions” section and you can turn off email notification

Ok, I’m cutting down the number of different variants. A few questions (probably for @mflatt): 1. Is there a reason to build/test cify versions of cgc if we’re doing that for 3m as well? 2. Is there a reason to test cify at all on macos?

1. no
2. no, one platform is enough

For the cify try, does building 3m involve building CGC with cify first, anyway? Or does that use an earlier Racket build to xform for 3m?

right now, the cify 3m build uses the cify cgc build

i could keep that, or could change the cify 3m build to use the regular cgc build

I guess there could be a bug that affects cify with CGC and not 3m. But probably that’s unlikely enough to ignore.

I wonder whether the 3m build should use CS instead of CGC, though. Maybe it doesn’t matter.

right now the cs build uses cgc instead

probably we should change that so that cs builds the way make does since that’s more important

but that’s a separate change

Ok

Also right now a few jobs run on pull requests that I think are not needed, like ARM32 and ubsan/asan

For the asan build (most recent failure here: https://github.com/racket/racket/runs/3146398093?check_suite_focus=true) my guess is that asan is in fact killing the build because of a sanitizer error

Well I just tried it locally and that isn’t what happened :disappointed: