Then situation is a bit better now, since we did not continue to submit as many
Para. However, the builds are still lagging (there are ones from 20hr ago
running). I see many of the new "cancelling duplicates" jobs queued but they
have not yet run.
I have cancelled a few myself. In case I cancel
> Also, I agree about simplifying macOS build if it will help while we get to q
> better situation.
We can have a special test list for macOS that includes just a few
configs from the simulator and other chips.
> There has been some talk about supporting non hosted runners, but there are
some se
On Wed, Mar 31, 2021, at 09:33, Abdelatif Guettouche wrote:
> > Also, I agree about simplifying macOS build if it will help while we get to
> > q better situation.
>
> We can have a special test list for macOS that includes just a few
> configs from the simulator and other chips.
I think just dr
On Tue, Mar 30, 2021, at 21:44, Brennan Ashton wrote:
> We were sharing cache but ran into some strange issues with collisions and
> disabled it unfortunately.
Do you remember the exact issue?
What if we had one ccache cache per : run shared across runs?
(not sure if that would be too much stora
> Anyway, I see the "other" includes a very long list of very different
> platforms. Maybe splitting it into avr, risc-v, xtensa could help?
When Xtensa was merged with "others" it had only 3 configs: nsh,
ostest and smp. Now it contains around 30, and surely more to come..
I agree that we shoul
On Wed, Mar 31, 2021 at 9:05 AM Matias N. wrote:
> Then situation is a bit better now, since we did not continue to submit as
> many Para. However, the builds are still lagging (there are ones from 20hr
> ago running). I see many of the new "cancelling duplicates" jobs queued but
> they have not
On Wed, Mar 31, 2021, at 11:26, Nathan Hartman wrote:
> I wonder if we need the tests to be a bit smarter in restricting what they
> test.
>
> For example if the change only affects files in arch/arm/stm32h7 then only
> stm32h7 configs will be tested.
That can be difficult to do. A header might
On Wed, Mar 31, 2021 at 1:13 PM Matias N. wrote:
> My reasoning with the per board+config ccache is that it should more or less
> detect
> something like this without hardcoding any rules: only files that are
> impacted by any
> changes in the current PR would be rebuilt, any other file would be
We're already using ccache, but it is used intra run (ie, for arm-01, sim,
etc). We tried persisting it across runs (from different PRs) but it seems
there was issues with that.
What I suggest means we have one cache pero board/config. The scripting
shouldn't be too difficult but it requires mu
