I agree with Brennan. If the ci build is too slow, let's optimize the ci process instead of bypassing it totally. Since I have checked almost all ci braak before, I expect that many board's config can't pass the compile without the guard from the ci system. Actually, I think the big imperfection of our ci is that the automation test is too weak, and many critical errors still can't catch by it.
On Tue, May 23, 2023 at 6:12 PM Brennan Ashton <bash...@brennanashton.com> wrote: > On Mon, May 22, 2023, 12:14 PM Nathan Hartman <hartman.nat...@gmail.com> > wrote: > > > On Mon, May 22, 2023 at 9:29 AM Sebastien Lorquet <sebast...@lorquet.fr> > > wrote: > > > > > > > > If the untold reason is to speed up github tests, then run less tests. > > > Do we really need to test build on 13 or 20 arm platforms when only one > > > config of the other architectures is tested, and the actual value of > > > these build test is dubious? > > > > My grumbles about build times it not about CI (although I would love for > the steps like clean to not be so slow). I would be quite opposed to > letting PRs through without passing current build tests as in the past > anything touching common code has broken builds in unexpected ways leaving > other people to clean the mess up. > > We already have ways to limit what builds are run based on the files > changed so if we wanted to skip builds in the cases that only certain > board/arch changes are a touched that is possible with someone willing to > do the work. > > You will note if you change only files in Documentation/** only the docs > get built. > > I have also asked in the past about cutting down on the amount of configs > we have checked in to be something like > > board:nsh -- only nsh and somewhat small > board:jumbo -- nsh, plus as many features as can fit and are interesting in > the platform. > > For sim and some other targets it would make sense to have more targets, > but not for every board. > > --Brennan >
