Hi Tom,
On Wed, 12 Jun 2024 at 11:07, Tom Rini trini@konsulko.com 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 jiaxun.yang@flygoat.com
.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