Here's an easy fix we should try: In each PR, CI should *not* run until approved by a human. And humans should *not* approve CI to run until *after* the PR has 2 approving reviews.
Why this will help: Currently, heavy CI runs on every PR right away. If the PR author pushes more changes (even to fix a typo) all the CI runs again. If reviewers request changes and the PR author pushes more changes, all the CI runs again. This adds up fast. Multiple rounds of heavy CI for every PR. So we reverse the order: First, humans will review the PR to see if it even makes sense. If it makes sense, we do our normal reviewing, request changes if needed, rinse & repeat... Once there are 2 approving reviews, that means we have a good confidence in the PR. So we manually approve CI workflows and wait for the results. Also, some PRs may not even need CI to run at all!! For example, PRs that only change comments, typo fixes, or small "obvious" fixes where the humans can clearly see that CI isn't needed. Then, we use Human Judgment (something Artificial Idiocy will never be able to do) and we can merge the PR without wasting the limited CI resources. WDYT? Nathan This message was written by: Human Brain Assisted by: Coffee with 2 sugars. On Fri, Oct 23, 2026 at 11:29 AM Alan C. Assis <[email protected]> wrote: > > Hi Bob, > > Thank you very much for this information. > > We already implemented some of these suggestions you found with AI help, > like ccache and the proper board map should be the next step. > > Another option we discussed some time ago was creating a single full board > profile with all the board features. > > This would allow us to avoid testing all board profiles, which currently > takes a lot of time. > > BR, > > Alan > > On Fri, Oct 23, 2026 at 5:53 AM Robert Thomson <[email protected]> wrote: > > > Hi Nuttx project, > > > > Further to my last mail of 2026-08-03 20:09: > > https://lists.apache.org/thread.html/cncnnxz5lvfyz7of8qgm2cq875fxp6f9 > > , we are seeing your project at the top of the list for consumption of > > GitHub hosted Actions runners for the past week, 50% higher than the > > 2nd most consuming project. > > > > In addition to the information I provided last time, I have included > > some suggestions from prompting Claude to examine your project repo's > > workflow code thus, "Analyze the GitHub Actions workflows in this repo > > and suggest changes that would be beneficial for the goal of a) > > Reducing the number of concurrent workflow jobs started and b) The > > duration of the jobs that do start https://github.com/apache/nuttx " > > > > The suggested changes are listed below, of course generated by GenAI, > > so use your discretion and own reading there and I am no GitHub > > Actions SME, so have not curated them, just listed them here. > > > > Note, there is also now a skill available that has been developed by > > the magpie project which can be used to give more detailed feedback on > > CI: > > > > https://github.com/apache/magpie/blob/main/docs/repo-health/README.md#workflow-optimization-experimental > > > > Make every effort to optimise your usage ASAP as the near constant > > 100% utilisation of our available GitHub hosted runner jobs is making > > it practically impossible for all projects to get their CI jobs to > > start and complete in a reasonable length of time, and it is incumbent > > on all projects to do their part to help other projects get their fair > > share of this limited resource. > > > > Thanks. > > Kind regards, > > -Bob Thomson, > > on behalf of ASF Infrastructure > > > > Apache NuttX > > > > Fewer concurrent jobs > > > > In Fetch-Source, map changed paths to board groups (using the globs in > > tools/ci/testlist/*.dat) and pass the result to the Linux matrix. This > > replaces the label-based selection in arch.yml, which only shrinks the > > matrix for PRs labeled exactly Arch+Size or Board+Size. > > Replace the four *-Arch selector jobs with one job that outputs all > > selections. Delete macOS-Arch and the macOS job, since arch.yml always > > skips macOS. > > Add max-parallel: 3 to MemBrowse analyze, and gate it on the same > > board selection or on Build succeeding. > > Add a paths: filter (**.py, **.yml, **.yaml, setup.cfg) to lint.yml. > > If it’s a required check, adjust branch protection first. > > Add github.event.workflow_run.conclusion != 'cancelled' to the if: in > > depends-on-comment.yml. > > In membrowse-comment.yml, check the step if: env.MEMBROWSE_API_KEY != > > ''. A step’s if likely can’t see its own env:, so the step may never > > run. > > > > Shorter jobs > > > > Make PR jobs restore-only for ccache (actions/cache/restore). Add a > > nightly job on master that saves it under a stable key, since PRs > > currently start cold. > > Change the Linux artifact upload from if: always() to if: failure(), > > and set retention-days. > > Replace fetch-depth: 0 in check.yml and lint.yml with a blobless > > filter or a limited depth. > > Add timeout-minutes to the Linux and MemBrowse jobs. > > Cache or bake into the image the per-job pip install ntfc and > > test-case clone, and enable buildx caching in docker_linux.yml. > >
