-
Notifications
You must be signed in to change notification settings - Fork 26.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flutter dashboard does not refresh luci builds data as expected #66846
Comments
The build dashboard data endpoint The benchmark data for the performance dashboard is stored on 15 min intervals. Should that be reduced to 1 minute as well? Is it possible that this is running on a cron job when it should be using a pub-sub? |
We are not adding pub/sub for prod builds yet but that is a very good idea. We can just add a pub/sub topic to the prod builder requests and process the data as we are getting it rather than polling the server. |
Moving out of the infra ticket queue because the implementation will take more than a couple of days |
Maybe related. There used to be a bug when refreshing chromebot status, and got fixed in flutter/cocoon#963. |
I looked into this some more. We need to set the notifier of LUCI prod builds to point to a flutter-dashboard pub sub. This requires changes in both flutter/infra (LUCI schedules the initial build) and flutter/cocoon (schedules reruns). There's the existing pubsub handler luci-status-handler which forwards updates to github checks for try jobs. For simplicity, we can create a prod version of the pubsub, and look into refactoring the duplicate logic later. We'll also need to figure out why flutter/cocoon#992 failed with Json encoding the LUCI requests. |
The DeviceLab LUCI tests now upload their results during the recipe. This allows for quicker updates than the current LUCI cron job. Depending on the complexity of adding pubsub to LUCI prod builders, it may be better to generalize the devicelab upload for all Flutter builders. |
I updated the git on borg mirror fetch cron from the default of 15 mins to 5 mins for the Flutter GitHub mirrors. This should reduce the time it takes for commits to be picked up by LUCI from average of 7.5 mins to 2.5 mins. 5 mins is the minimum the GoB fetch allows. If needed, we can send an RPC to the GoB backend to update based off the GitHub webhooks
|
Can we do the same for the engine repo? /cc @zanderso FYI Although I thought this bug was related to the cells not being updated because of the cache and or the latency to process build status. |
I applied to all mirrors in the Flutter org (there was only one config).
This helps with getting gray->yellow quicker on LUCI tasks. I documented this here as it's not obvious why there was occasionally a 15 min delay in the a task going from gray to yellow. |
gray=>yellow means status from |
I fixed the fetch timeout. There were configs for each repo. For some reason, flutter/flutter was set to sync every 30 minutes.
I believe the issue is that LUCI is based on this GoB repo. It cannot schedule builds for a new commit until the commit has been mirrored from GitHub to GoB. To validate a commit on LUCI we end up with the following time breakdown:
1 affects gray -> yellow timing |
Thanks for the explanations. |
\cc @CaseyHillers can we close this one or are we still missing something? |
No. Cocoon still relies on the cron based method for updating LUCI tasks on the dashboard. Unassigning myself as i'm not actively working on this. \cc @yusufm |
Assigning to Yusuf, this impacts the team and it prevents the adoption of the flutter-dashboard for teams different than framework. |
This is currently blocked on flutter/flutter waiting to move onto the cocoon scheduler, which should fix this. |
Deduping with #92300 |
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of |
The expectation is that flutter build dashboard tasks are updated in a max 2 mins after the luci build completes. The observed behavior is that sometimes the tree is closed for more than 15 mins after a red task has become green.
I think this is a problem in two areas:
\cc @CaseyHillers @keyonghan
The text was updated successfully, but these errors were encountered: