Hi Nathan,
I think Michal is right, even an inoffensive comment could generate a CI
error as we just saw yesterday:
usbhost/usbhost_max3421e.c: In function 'max3421e_enumerate':
Error: usbhost/usbhost_max3421e.c:3606:23: error: missing terminating '
character [-Werror]
("mea culpa, mea maxima culpa")
Also, I think the idea of requiring manual PR approval to start o CI will
cause the opposite issue: many PRs will accumulate and be triggered
together (because only two or three developers are looking at the CI).
BR,
Alan
P.S.: I noticed some emails from the dev@ mailing list are not arriving in
Gmail (I didn't receive Nathan's email, I saw it via Michal's reply). Is it
happening to more people here?
On Fri, Oct 23, 2026 at 5:25 PM Michal Lenc <[email protected]> wrote:
> Hi,
>
> > 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.
>
> would it be possible to persuade Github actions to run only some jobs
> automatically and the rest after manual command or approves? I think
> basic pull request/commit and lint jobs, those first 6 checks before
> builds, can run automatically. They are not long or resource consuming
> and they give the contributor and reviewers the initial feedback if the
> PR is at least formally ok.
>
> But generally I agree, a lot of PRs run the same jobs over and over
> again because of changes (even small ones) during review process. We can
> run the builds after approves/before the merge.
>
> > 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.
>
> I don't think this is the right direction. Yes, there are some PRs that
> don't need it at all, but I would avoid merging PRs to master without
> running at least limited CI. Even human judgment can make errors, so
> let's try to avoid it. :) Also the amount of these kind of PRs is really
> low (my subjective feeling), so the benefit of jobs reduction won't be
> big. And this way Github could start the jobs automatically after two
> approves and block the merge until jobs pass.
>
> Michal
>
> On 10/23/26 18:50, Nathan Hartman wrote:
> > 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.
> >>>
>
>
