lupyuen commented on PR #17197: URL: https://github.com/apache/nuttx/pull/17197#issuecomment-3442684876
> However, it's a good idea, so it might be worth making this change, but first we also need to think about how to bypass the check step. @simbit18 Yeah I'm a bit worried about doing any "emergency bypass", like when the CI fails during NuttX Release and we scramble to fix the CI. Also we have a Critical Expertise problem in NuttX CI, only you and I understand how the CI works :-( > The goal here is to reduce how often those parallel jobs run unnecessarily during normal PR development (for example, on drafts or failed checks), not to remove or serialize them completely. @trns1997 Actually running "unnecessary" jobs might not be a bad thing. Compare the Current CI vs Proposed CI: - __Current CI:__ Suppose all 3 steps fail: Check , Lint and Build. The developer sees all 3 failures immediately and fixes all 3 failures altogether in a Single PR Update. Which requires only 1 re-run of the CI. - __Proposed CI:__ Suppose all 3 steps fail: Check , Lint and Build. The developer only sees Check Step failure, fixes it, updates the PR, re-runs the CI. Then the Lint Step fails, we fix it, resubmit and re-run the CI. Finally the Build Step fails, we re-fix, re-submit, re-run the CI. Which means more CI Jobs, and probably more developer frustration ;-) - __I'm also thinking:__ The Current CI runs all Build Jobs in parallel: arm-01, arm-02, .... And we don't cancel the Entire CI Workflow immediately if any build fails, we always wait for the Build Job to complete. This will help our developer to fix all build errors in One Single PR Update. The Proposed CI seems to go against the current thinking? So sorry I find it a bit difficult to accept the Proposed CI changes. If we had more folks to maintain NuttX CI (especially during the critical period of NuttX Release), then we might be able to accept the changes. But right now, it's just too risky sorry :-( -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
