Re: Creating a build system which can scale. #yocto


Robert P. J. Day
 

On Mon, 17 Feb 2020, Quentin Schulz wrote:

Hi Philip,

*Very* quick and vague answer as it's not something I'm doing right now.
I can only give hints to where to look next.

On Mon, Feb 17, 2020 at 04:27:17AM -0800, philip.lewis@domino-uk.com wrote:
Hi,

I'm looking for some advice about the best way to implement a
build environment in the cloud for multiple dev teams which will
scale as the number of dev teams grow.

Our devs are saying:

*What do we want?*

To scale our server-based build infrastructure, so that engineers
can build branches using the same infrastructure that produces a
releasable artefact, before pushing it into develop. As much
automation of this as possible is desired..

*Blocker* : Can’t just scale current system – can’t keep throwing
more hardware at it, particularly storage. The main contributor to
storage requirements is using a local cache in each build
workspace and there will be one workspace for each branch, per
Jenkins agent: 3 teams x 10 branches per team x 70Gb per
branch/workspace x number of build agents (let say 5) = 10Tb. As
you can see this doesn’t scale well as we add branches, teams or
build agents. Most of this 10Tb is the caches in each workspace,
where most of the contents of each individual cache is identical.
Have you had a look at INHERIT += "rm_work"? Should get rid of most of
the space in the work directory (we use this one, tremendous benefit in
terms of storage space).

c.f.
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#ref-classes-rm-work
in addition, you can always override that build-wide setting with
RM_WORK_EXCLUDE if you want to keep generated work from a small set of
recipes for debugging.

rday

Join yocto@lists.yoctoproject.org to automatically receive all group messages.