-
Notifications
You must be signed in to change notification settings - Fork 29.7k
improve trace logging in packages autoroller #154441
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
improve trace logging in packages autoroller #154441
Conversation
| '-b', | ||
| 'packages-autoroller-branch-1', | ||
| ]), | ||
| const FakeCommand(command: <String>[ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We only called this to ensure the tool was built, but the next command was calling the bash script that would ensure its built anyway, so this was redundant.
|
Windows build_tests_1_7 failure was this: #154453 |
|
Time to revert pull request flutter/flutter/154441 has elapsed. |
|
Reverting. The signal is strong that this broke the tree. |
Add debugging to diagnose: flutter#154151
Reverts #154441 https://ci.chromium.org/ui/p/flutter/builders/prod/Linux%20packages_autoroller/11826/overview I can't see how this change would be causing the specific failure on the tree, but the failure is consistent after this commit, so speculatively reverting. The revert label isn't working since we're out of the window, so this is a manual revert.
Reverts #154555 Re-lands of #154441 and #154369 New changes in this PR: 1. extend timeout of the `Linux packages_autoroller` shard (see step 14 in this example [LED build](https://ci.chromium.org/ui/p/flutter/builders/prod.shadow/Linux%20packages_autoroller/7/infra)) 2. use the managed framework repo as the working directory in the `framework.streamDart()` helper function--we were generating gradle lockfiles in the wrong directory A LED build with this code generated the following gradle lockfile update: d939981
Add debugging to diagnose: #154151