Muzzle CI experiment #5594
Muzzle CI experiment #5594
Conversation
instrumentation/build.gradle.kts
Outdated
| } | ||
| } | ||
|
|
||
| // TODO (trask) how to know that muzzleTasks populated above before used below? |
There was a problem hiding this comment.
If the muzzle tasks are actually being run then maybe it's OK but indeed this pattern doesn't look quite reliable. I don't know if it's important for us to split the list into 1111222233334444, if 123412341234 is OK I would create the tasks first and then in the plugins.withId callback AtomicInteger.getAndIncrement() % muzzleTasks.size() to pick the task to register into.
Alternatively we would need to use evaluationDependsOn and afterEvaluate, but reducing evaluation order dependencies tends to help understand the build.
There was a problem hiding this comment.
if
123412341234is OK I would create the tasks first and then in theplugins.withIdcallbackAtomicInteger.getAndIncrement() % muzzleTasks.size()to pick the task to register into.
ya, I like that, do you know if the subprojects ordering is guaranteed to be the same across multiple invocations (on same git sha)?
There was a problem hiding this comment.
As far as I know Gradle project evaluation order is deterministic (a DFS) which would make this deterministic too, though I can't say with 100% confidence without trying
There was a problem hiding this comment.
There was a problem hiding this comment.
Here we're relying on project evaluation order, not task evaluation order. Luckily, project evaluation order is defined by Gradle
https://docs.gradle.org/current/dsl/org.gradle.api.Project.html#N14CB4
Co-authored-by: Anuraag Agrawal <[email protected]>
* Muzzle CI experiment * Fix class loader leak * --max-workers=4 * Concurrent jobs * Update .github/workflows/muzzle.yml Co-authored-by: Anuraag Agrawal <[email protected]> * Simpler * Add link to comment Co-authored-by: Anuraag Agrawal <[email protected]>
notes:
single muzzle CI job with all modules took (after fixing class loader leak that doesn't affect the javaagent since
javaagent-instrumentation-apiis always loaded in the bootstrap class loader outside of muzzle):--max-workers=4--max-workers=8went with
--max-workers=4to avoid overtaxing and causing failuresthen I split the muzzle jobs out into 4 jobs. I think github actions re-run may not understand dynamic matrix(?), so this could still solve the re-run issue.
I'm not sure if the 4 job split-out is worth it, so thinking of reverting that (see last commit). It did get the muzzle time down to 10 min (x4 parallel jobs).