-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Await Fast CI #33241
Await Fast CI #33241
Conversation
Update an example build to call the await-fast-ci.yaml job which currently just echos
PR #33241: Size comparison from 416f6a3 to 0331c14 Full report (38 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, linux, mbed, nrfconnect, nxp, psoc6, qpg, stm32)
|
PR #33241: Size comparison from 416f6a3 to cf2bf37 Full report (4 builds for cc32xx, mbed, stm32)
|
PR #33241: Size comparison from 416f6a3 to 26da209 Decreases (2 builds for efr32)
Full report (71 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, mbed, nrfconnect, nxp, psoc6, qpg, stm32, telink)
|
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.
Sorry, click wrong approve button, may I get to know the goal for this PR?
PR #33241: Size comparison from 1919112 to 601d67e Full report (85 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, mbed, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
@yunhanw-google - please see attached issue. The goal is to cancel the slow-running CI targets when the fast targets fail, so we don't spend multiple hours of CI time running jobs when we know the PR will need to be updated. |
And what about the case when someone would like to know all failing platforms (workflows) in advance? In case of fast failure, CI will report only the first one. Then one will fix it and learn in another x minutes that another platform (workflow) fails... I know that preferably it would be nice to test everything locally before pushing to upstream, but it's not that simple with constrained development environment (storage, RAM, CPU) and so many platforms to test. Other possibility is to test CI on local fork and then create PR. However, such approach will double the CI time in most cases (there was already a case reported by GitHub, that this project uses too much GitHub Actions resources dedicated for ALL open source projects). I hope that we will not end up in a case similar to Darwin matrix workflow were one flaky workflow stops others, so instead of rerunning one job it is required to rerun two or three. |
For simple cases like CLA or restyled there is already an action that can pause a job before other is completed: https://github.com/marketplace/actions/wait-on-check IMHO it's better not to spawn any jobs if restyle (or other simple check like that) does not pass. So, for such approach see https://github.com/marketplace/actions/wait-on-check#alternatives maybe one of these will be useful. |
Seems these options run into the same issues as the stop on fail action when I tested them, where permissions are missing and appear to be unobtainable with even an allow-everything token. |
Closing this as obsolete - we have a separate implementation since #36000 |
#32735
Created as a draft to prototype functionality