Backfiller misses soon-to-be-beta (but not yet) branches
#169234
Assignees
Labels
infra: cocoon
Related to the dashboard or cocoon server
P2
Important issues not at the top of the work list
team-infra
Owned by Infrastructure team
Comments
auto-submit bot
pushed a commit
to flutter/cocoon
that referenced
this issue
May 22, 2025
…4719) I started to work on flutter/flutter#169234 and realized the current way timestamp filtering is done with Firebase is inflexible (and personally, confusing). This adds a small-ish `TimeRange` class in `cocoon_commons` and uses it instead of `int? timestamp` to determine which commits to find. (Even if we want a different approach than flutter/flutter#169234, this seems worth it?)
auto-submit bot
pushed a commit
to flutter/cocoon
that referenced
this issue
May 22, 2025
…4721) Closes flutter/flutter#169234. This could be made a (dynamic) flag if needed in the future, but I don't see the need for now.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I was surprised to see that the (candidate) branch
flutter-3.33.0-candidate.0was left in a "Waiting for backfill" state in 678de86.The cause is because the back-filler is subtly hard-coded to run on:
mainormaster) branch for supported repositoriesflutter-X.XX-candidate.X) that are currently live on the respectivestableorbetabranches in flutter/flutterflutter/flutter/ios-experimentalUnfortunately that means that new, but not yet published, candidate branches are missed.
For
flutter/flutter, the only repository where new branches are supported, we could (1) consider backfilling any branch that has had a commit as a result of a merged PR in the past{DURATION}, say the last 7 days. The other option (2) is a semi-manual trigger, i.e. adding branches that request aRun all tasksto a TLLd "watch this branch for the next N days".If we could pull off option (1) it has less manual components and does not require more state tracking.
The text was updated successfully, but these errors were encountered: