cats-effect
cats-effect copied to clipboard
typelevel
Scala Native
Is there a way to limit the number of concurrent jobs? Now that the matrix has grown past 20, this is using all of the org's runners.
Yeah, that is indeed annoying 😕
GHA does have some controls for concurrency. I think to make it work though we'd have to split the matrix roughly in half (two batches of 10) and enforce that only one such batch may be running at a time across the entire repo. https://docs.github.com/en/actions/using-jobs/using-concurrency
On the other hand, this will suck when its crickets everywhere else but we're trying to do something here.
Another alternative I've thought about is running a slimmer CI matrix for PRs and using the full matrix only on merges.
Is there a way to limit the number of concurrent jobs? Now that the matrix has grown past 20, this is using all of the org's runners.
I'm honestly not sure it can be helped. Cats Effect is often affected by the other direction of this problem, btw, where builds on Cats or Fs2 can eat up runners and cause builds here to take a remarkably long time. Gating concurrency doesn't really solve the problem, which is that we can't get more runners without paying a significant premium (and even then we don't get many).
This is a better discussion for the maintainers forum. This is strangling us all. I'll move it there.
@keynmol kindly reports that all tests are passing on macOS M1 + 2.13 + Native
So this is all in series/3.3.x now right? How do we untangle the git gordian knot?
No, this is not really in series/3.3.x. Actually pulling that off would have been too painful because Scala Native requires Scala 3.1+ and the JVM/JS series/3.3.x is stuck on Scala 3.0. Hence my "backport" PR https://github.com/typelevel/cats-effect/pull/3138 really started a parallel branch series/3.3.x-native. That branch can simply be abandoned.
Yes, sorry, not ideal. But I wasn't prepared to let this die-on-the-vine like my Env PR from *checks watch* ...
Yes, sorry, not ideal. But I wasn't prepared to let this die-on-the-vine like my Env PR from checks watch ...
whistles innocently
Either way, given that this has now been released, I think it's best if we get it into series/3.x to form a part of 3.4. :-)
Ok, @djspiewak, let's land this one :) tbh I was quite sad to ship this out in 3.3.14 without your review, so I'm looking forward to that 😇
Question: do we want to add a macOS CI job? There a couple places where we directly call native APIs (high-precision time and cryptographically strong random numbers). They are all supported on Linux/macOS, but in theory we should be careful.
Question: do we want to add a macOS CI job? There a couple places where we directly call native APIs (high-precision time and cryptographically strong random numbers). They are all supported on Linux/macOS, but in theory we should be careful.
I hate to say it, but we should be careful. :-( So that means one more matrix entry.
Something I haven't done in this PR is setup the test harness so we can run the IOAppSpec with Native executables. It's possible by the same trick we use to run the IOAppSpec for JS. So just a yak I'd be happy to put off 😆