https://pact.io logo
Join Slack
Powered by
Looks like our monthly compute limit was exceeded....
# maintainers
m
Looks like our monthly compute limit was exceeded. Will need to find a solution, as its blocking a Pact JS Core release 🧵
boo 1
If I understand correctly, there are two paths we can take for (at least Mac M1and Linux ARM support): 1. Use their runners and add credits (minimum $20 USD per credit purchase) 2. BYO infrastructure (e.g. AWS) I’m confident I could get SmartBear to pay for either, probably, but definitely the AWS account. It would need to be made a child account of another SmartBear, but just for billing purposes. We’ll retain admin permissions
I recall Yousaf did some numbers a while back, but that will be lost to slack history (probably, as I think it was before we made a public maintainers channel)
I’d like to support them (Cirrus) if I can, and buying credits isn’t that expensive. I think we could double our usage for about $20 USD a month. It’s hard to know if we’d go much over that, because usage has been capped since they introduced limits:
y
Hey chap, Oh noes. I found the thread https://www.linen.dev/s/pact-foundation/t/13592341/aww-sad-news-about-cirrus-ci-and-free-runner-use-https-cirru hmmm so that would be $117 for Mac credits + $15 for Linux = $132 /mth Cirrus pricing https://cirrus-ci.org/pricing/#compute-credits 1000m = 15 credits = $15 66.66667m = 1 credit = $1 1m = 0.015 credits = $0.015 GitHub pricing https://github.blog/2023-10-02-introducing-the-new-apple-silicon-powered-m1-macos-larger-runner-for-github-actions/ MacOS M1 is $0.12 a minute for large, $0.16 for XL on GH These are 3/4 vcpus, whereas Cirrus costs are per vcpu GH looks to be, by my naive calculations cheaper, plus is higher aligned with our other workflows, only thing we would miss out on would be arm64 linux but we would probably be able to get away with arm linux under our free tier on cirrus
fyi, I’ve built the prebuilds for arm64 versions on my laptop and added them to the draft release, and kicked off the failing release check, so that will get us out of a bind for the mo
thankyou 1
m
Thanks for doing that dude, that’s great.
What about running our own hosted runners for Github on e.g. Amazon Mac and linux ARM agents?
Is another option reducing what gets built on those runners to purely master builds/release only?
(that might already be the case, btw)
y
Is another option reducing what gets built on those runners to purely master builds/release only?
limiting builds is prudent, I was a bit fast and loose whilst there was no limits.
What about running our own hosted runners for Github on e.g. Amazon Mac and linux ARM agents?
Yeah that isn’t a bad shout, the gh images are available (they use Packer) so we can make sure they have near enough the same stuff on them. We can limit their use as well to keep costs down
👍 1
m
Is the pricing with GitHub per user though? I seem to recall that was the reason we couldn’t do that in the past
j
Pretty sure GitHub is per minute of use of each worker. Also regarding the 
aarch64
Linux builds, I get around that for Pact Python by using 
qemu
virtualisation and a 
aarch64
Docker image. It is slow, but at least it works. This would ensure that everything basically runs the same.
👍 1
Open in Slack
PreviousNext
Powered by