acassis commented on issue #17914:
URL: https://github.com/apache/nuttx/issues/17914#issuecomment-3755280172

   > > [@linguini1](https://github.com/linguini1) seems like we are in a stage 
similar to what Greg was facing where he are doing "CI" in machine. We thought 
that after moving to Apache Foundation all our problems will be fixed, this is 
very disappoint.
   > > I think they should allows to use more than 25 runners, because this is 
the amount allowed to all projects, even projects that are not active anymore. 
It should be better to redistribute it between active projects (maybe the 
situation is a little different than what I'm seeing, but who knows?)
   > > Maybe we will need to run local machines to do the CI and just send the 
result to github, but since our user base is small I don't know if we will have 
enough computing power this way
   > 
   > I agree it would be nice if resources were redistributed, but I think we 
can still get a little more clever with our CI. I remember Lup made some really 
big improvements before. For instance, now we don't run a full build on every 
documentation change, just a docs rebuild.
   > 
   > I wonder if we can try to do something similar again. Ex: changes to 
documents under `arm/rp2040` only perform builds of rp2040 boards. It's going 
to be hard to do that for everything but it might be a better option than self 
hosting?
   > 
   > Also, I wonder if we can cut down on "duplicate" boards in the regular CI. 
As in, it's not necessary to test a rebuild of every SMT32H7 board when there's 
a change, just one should be fine in most cases.
   
   Yes, we discussed this idea with @lupyuen in the past: if a PR is only 
modifying an specific board it doesn't make sense to test all other boards of 
the same arch. And if only a chip from a specific arch is modified it doesn't 
make sense to test all ARM boards.
   
   But I think these rules are difficult to implement on our CI. Maybe we need 
to rethink our CI from scratch


-- 
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]

Reply via email to