Repository navigation
Test BOLT builds in CI #128515
Description
Activity
JIT project currently use LLVM 19, I think that we can specify same version as well.
cpython/.github/workflows/jit.yml
Lines 63 to 64 in b60044b
@hugovk cc @zanieb
It will take around 20 minutes running time, I guess.
Is it okay to add the CI when PR is merged to the main branch only?The other option will be adding it to the build bot through my Azure machine with OSS credit. But we may need to get sponsor if it requires more than 2vcpu + 8gb ram.
Is it okay to add the CI when PR is merged to the main branch only?
Do you mean run only after a PR is merged? I'm less keen on this, it would mean if a PR breaks it, we won't see it immediately until after merging the breaking change. And it could be some time before someone notices a post-merge build fails, and it would take time to track it down.
I think it would be better as part of the main CI so we catch breaks before merge.
Because it needs LLVM, does that mean it will this need to be a new job, and we can't add it to an existing job?
Here's a visualisation of a recent build of the main build workflow from Datadog 🔒:
The total build was 23.5 mins.
The current bottleneck is free-threaded Windows, the yellow bars, at 22.5 mins.
The next are 3 x CIFuzz, the purple-ish and blue bars, at 19-21.5 mins.
We get max 20 concurrent jobs (but only max 5 for macOS), but I'm hoping we can get upgraded soon. Anyway, I think it should be okay to add a new job.
Reacted by Zanie Blue- added a commit that references this issue
on Jan 18, 2025
Feature or enhancement
As part of #101525, we should run BOLT optimizations in CI.
It looks like optimizations aren't tested in CI right now, just on the build bots? I could use some guidance on the best place for this.
Linked PRs