Hi Tom, On Wed, 12 Jun 2024 at 11:07, Tom Rini <[email protected]> wrote: > > On Wed, Jun 12, 2024 at 05:14:46PM +0100, Jiaxun Yang wrote: > > > > > > 在2024年6月12日六月 下午5:01，Tom Rini写道： > > > On Tue, Jun 11, 2024 at 10:04:13PM +0100, Jiaxun Yang wrote: > > > > > >> Current build_world task runs for too long on public gitlab > > >> runner. > > >> > > >> Split the job as what we've done to azure pipeline. > > >> > > >> Signed-off-by: Jiaxun Yang <[email protected]> > > >> --- > > >> .gitlab-ci.yml | 103 > > >> +++++++++++++++++++++++++++++++++------------------------ > > >> 1 file changed, 59 insertions(+), 44 deletions(-) > > > > > > I don't like this. The list in Azure is because of the time limits there > > > and in turn we: > > > a) Have to tweak it periodically to keep things from running too long > > > b) Have to tweak it to ensure that we don't miss some new SoC/etc > > > > Then it will render running CI test on gitlab.com impossible again :-( > > Yeah, it's not something I'm the happiest with. Looking around a bit, I > see a blog post that talks about dealing with dynamic variables, in > Azure. So we could, I think, figure out some logic to have each build > stage say what platforms it covers. And then have a final step that > compares all of the platforms built vs the global list (just > tools/buildman/buildman --dry-run -v) to make sure nothing was missed. > With something like that, and assuming GitLab can do it too (it probably > can), I'm OK with having the world build be broken down to 10 groups > (maximum number of parallel jobs in Azure CI for free) since we'll know > if we miss something too. > > So lets set this patch (and the doc update) aside for now, unless you > want to look at the above. I'll look at the above soon.
Could we hook up one of our machines as a public runner somehow? Regards, Simon
