Github actions

[gnzlbg]

@pietroalbini could we enable github actions for libc ? It has many more buildjobs than Azure, and for libc that's a huge bottleneck.

[gnzlbg]

cc @alexcrichton

[pietroalbini]

I can't see why not.

[alexcrichton]

I'd want to be a little wary of this because according to their documentation we get 20 concurrent jobs across everything, and while that won't include rust-lang/rust it's not a reason for this or other repositories to go hog wild and add hundreds of builders. I would ideally want to see that the number of builders taken up by libc on github not be that much higher than on azure.

I've personally thought from time to time that the libc CI is a bit too ambitious and if it is causing issues with PRs then it should likely be scaled back appropriately.

[pietroalbini]

@alexcrichton well, our plan is actually "GitHub Team" (link only for org owners), so we get 60 builders across the rust-lang org. If libc limits their concurrency to like 20 parallel builders I don't think that's going to cause issues for othe repos.

[gnzlbg]

I'd want to be a little wary of this because according to their documentation we get 20 concurrent jobs across everything,

Oh, indeed. I thought the limit was 20 jobs per repository, but there are also limits for the whole org. Maybe this is not a good idea and sticking to the rust-lang2 azure org is the best way forward.

I would ideally want to see that the number of builders taken up by libc on github not be that much higher than on azure. [...] I've personally thought from time to time that the libc CI is a bit too ambitious and if it is causing issues with PRs then it should likely be scaled back appropriately.

The simplest way to scale it back would be to only run the tests for tier-1 targets here, and just check that tier-2 targets build. That should work fine with the 10 concurrent job limit.

[alexcrichton]

Ah if @pietroalbini is right then yes I think we should be fine. I think libc will want to use max-parallel though to scale appropriately, and 20 sounds like a good start.

[gnzlbg]

I think libc will want to use max-parallel though to scale appropriately, and 20 sounds like a good start.

I can do that, 20 concurrent jobs should be more than enough (we need around ~15).