bitbake of individual repositories

Patrick Williams patrick at stwcx.xyz
Tue Jan 7 02:10:41 AEDT 2020


On Thu, Jan 02, 2020 at 03:57:05PM -0600, Andrew Geissler wrote:
> > On Dec 18, 2019, at 12:02 PM, Patrick Williams <patrick at stwcx.xyz> wrote:
> > On Tue, Dec 17, 2019 at 04:02:12PM -0600, Andrew Geissler wrote:
> >> Other ideas out there?
> > 
> > I've mentioned repo before as it can assist with this.  Bitbake has a
> > feature where you can set "SRCREV=${AUTOREV}" and it will automatically
> > pick up what is in the git repo.  What I've done on another project is
> > this:
> 
> Does this mean all recipes will need to change to do this? I think we’ve
> discussed this in the past and stated we like to have more control over
> when code is picked up in the meta-* layers.

It is a pretty simple bbclass that you include in each recipe.  That's
all.

I want to be clear, that you still have the exact same control on what
code is picked up as you have today.  In general the SRCREV is set by
the recipe and is an explicit commit number (or tag), just like today.
Only in the case that a special environment variable is set does SRCREV
become AUTOREV and in that case you use 'repo' to populate exactly the
code you want.  There is never a case where you do not have control on
what code is populated or where you cannot reproduce a build.  All that
is happening is you are delegating responsibility of the SRCREV to repo.

> >   1. Use `repo` to pull down all the source repositories in a consistent
> >      tree (and ensure it is in the Docker build image, such as in
> >      /workdir).
> 
> I’m not familiar with repo. Will this require any changes to our upstream
> repositories or is this just a tool we can use from within our CI scripts?

I have another email chain with Brad where I think repo might be a
reasonable alternative to "merging all the metas together" problem, but
otherwise, they are not related.  You could use repo just for CI.  In
fact, I proposed that as a first step in that email chain (you were CC'd
I believe).

> >   2. Run a small script to fetch the GERRIT_REFSPEC and/or GERRIT_TOPIC
> >      on top of the checked out `repo` location.
> > 
> >   3. Add a small .bbclass that replaces "SRCREV=${AUTOREV}" when an
> >      environment variable is set and update the recipes to inherit
> >      this class.
> > 
> >   4. Set the environment variable prior to running `bitbake` and add a
> >      source mirror to point at the /workdir location instead of Gerrit
> >      directly (eg. 1 line in local.conf).
> 
> Your option seems even more complicated then the one’s I had above :)
> It does come with the added feature of the TOPIC support but our general
> statement has been to just avoid requisites.

I'd probably argue that it is just as complicated as trying to use
devtool to formulate a code package of sorts. ;)

> As with anything though, if you’re willing to put the work in to help make
> this happen, and assuming it requires minimal changes to existing
> repository layouts and recipes, I’d be interested.

I've written it once before but that wasn't open source.  Probably
wouldn't be too hard to recreate something similar.  I should have some
cycles to put towards on OpenBMC CI work the next two months.  I've been
wanting to prototype a `repo` example anyhow per that other email chain.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200106/b501c054/attachment.sig>


More information about the openbmc mailing list