Allow limiting total build-from-source dependents - #23884
Conversation
There was a problem hiding this comment.
馃煛 Changes recommended
The limit resets for each tested formula, so a runner can exceed the advertised total cap.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Adds an analytics-ranked cap on dependents built from source by brew test-bot.
Changes:
- Adds the hidden
--max-dependents-from-sourceflag. - Selects the most popular source dependents using analytics.
- Adds Sorbet declarations and unit tests.
File summaries
| File | Description |
|---|---|
Library/Homebrew/dev-cmd/test-bot.rb |
Defines the new limit flag. |
Library/Homebrew/test_bot/formulae_dependents.rb |
Applies source-build selection and limiting. |
Library/Homebrew/test/test_bot/formulae_dependents_spec.rb |
Tests filtering, limits and ordering. |
Library/Homebrew/sorbet/rbi/dsl/homebrew/cmd/test_bot_cmd.rbi |
Types the new argument accessor. |
Review details
Files not reviewed (1)
- Library/Homebrew/sorbet/rbi/dsl/homebrew/cmd/test_bot_cmd.rbi: File type not supported
- Files reviewed: 3/4 changed files
- Comments generated: 2
- Review effort level: Balanced
馃挕 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
88104dd to
538dc8b
Compare
MikeMcQuaid
left a comment
There was a problem hiding this comment.
Thanks, seems like a good idea. We should definitely cap (and randomise) this.
Do you have a sense of how often this source dependent building actually catches problems? I am inclined to say this could be set to a very low random number (~10 or something) and/or use analytics information to pick the most popular affected packages and just use those.
I wouldn't be opposed to removing this entirely.
For Rust, hard to say. Given CI takes too long, we've often had to ignore results. There is an ongoing sharded run right now (one shard finished 18h, some still running 22h+). Finished shard shows 2 checksum issues and 2 rust-related build failures (aider and mesa). Haven't checked but these may need backports or new release. For Go, we are able to take actionable steps for breaking changes (either by switching to older versioned Go or updating/backporting from upstream): Other formulae on source-build-deps list don't have crazy number of dependents. Build-specific tooling like
I went with analytics as I'd expect those to have more source builds.
Ignoring Go/Rust, would still want it for other formulae. Perhaps can consider removing Rust from list if reduced test doesn't actually catch anything. Go PRs do seem to result in actionable tasks, but Homebrew's Go users are still the noisiest if a release is not out right away, e.g. |
Yeh, sorry: I was suggesting we could perhaps use analytics to decide which source builds to perform dynamically at
I think we should be aiming to merge these straight away when they don't break our own bottles, honestly.
Yes, this is crazy, need to not do this 馃槶 |
Rust and Go PRs run for over 1 day and continue to grow in total dependents. To make these more reasonable, limit the maximum number of build-from-source dependents per runner (shard). Selected based on analytics data as more popular formulae are more likely to be built from source by users so identifying these earlier would allow reporting issues or opening PRs upstream.
538dc8b to
1674f4f
Compare
There was a problem hiding this comment.
馃煛 Changes recommended
Analytics ranking is applied per formula rather than across the runner-wide candidate set.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Balanced
| max = MAX_DEPENDENTS_FROM_SOURCE - @tested_source_dependents_count | ||
| source_dependents = [] | ||
| if args.build_dependents_from_source? && max.positive? | ||
| source_dependents, dependents = split_source_dependents(dependents, max) |
One possible idea for issue we have been discussing with overly long CI times.
This PR uses a limit ranked by analytics data. Other ideas mentioned were testing dependents with dependents, no longer source building dependents, etc.
Rust and Go PRs run for over 1 day and continue to grow in total dependents. To make these more reasonable, allow limiting the maximum number of build-from-source dependents per runner (shard).
Selected based on analytics data as more popular formulae are more likely to be built from source by users so identifying these earlier would allow reporting issues or opening PRs upstream.
Examples:
brew test-bot '--testing-formulae=rust' '--tested-formulae=rust' --only-formulae-dependents --junit --build-dependents-from-source
brew test-bot '--testing-formulae=go' '--tested-formulae=go' --only-formulae-dependents --junit --build-dependents-from-source
brew benchmarkresults.brewcommands to reproduce the bug?brew lgtm(style, typechecking and tests) locally?n/a