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?
Sometimes I get dev@ mails to spam or newsletters folder, maybe it's
there? Not using gmail but Czech provider though.
Michal
On 10/24/26 14:45, Alan C. Assis wrote:
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.
