tmedicci commented on issue #15730: URL: https://github.com/apache/nuttx/issues/15730#issuecomment-2676332575
> Isn't `citest` kinda slow? We won't know if any defconfigs have Build Errors until `citest` completes. Also our `citest` is a little wonky, it fails quite often according to [NuttX Build History](https://nuttx-dashboard.org/d/fe2q876wubc3kc/nuttx-build-history?from=now-7d&to=now&timezone=browser&var-arch=$__all&var-subarch=$__all&var-board=rv-virt&var-config=citest&var-group=$__all&var-Filters=) Oh, perhaps I wasn't that clear on my idea: I proposed to have a defconfig (not necessarily `citest`) that should be built before anything else. I didn't mean (at least not at this moment) to run runtime testing... the idea is to create more dependent workflows that, if failed, avoid other workflows from running (saving GitHub runners from being wasted unnecessarily). Let me provide a quick example: suppose a PR triggered all archs (because it's a general change, for instance). That would trigger a lot of parallel jobs for every arch. Instead of that, we should create an intermediary flow (target group) with a single defconfig for each board (`citest`, `nsh`, `ostest`, `hwtest`, it doesn't matter which now). If this target group fails to build, the other parallel jobs won't run. Instead of running +1500 jobs (every defconfig from all boards), we run a single jobs that tests the same defconfig for all archs/cips/boards. If this fails, it doesn't make sense to continue testing everything else. -- 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: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
