[OE-core] Running BitBake multiple times without rechecking upstream AUTOREV versions

chris.laplante at agilent.com chris.laplante at agilent.com
Fri May 11 18:23:03 UTC 2018

Hi all,

I'm working on using Jenkins to host our Yocto build. One of the things that would be nice is to be able to do a "bitbake our-user-image", upload the artifacts to our network file storage, and then do a "bitbake our-user-image -c populate_sdk_ext". I'd like to do these separately so that developers are not waiting around for the eSDK to be generated if all they care about is the kernel, for example. My concern is that the second bitbake invocation could end up building different stuff if someone were to check in code in between when the two "bitbake"s are run. This is primarily a concern with recipes that use AUTOREV (as we do for development purposes).

Is there a way to essentially "freeze" the BitBake data store and re-use it across multiple bitbake invocations?

I had a few ideas:

1. Use buildhistory-collect-srcrevs to generate the SRCREV_pn- overrides necessary to lock the SRCREVs of all the packages.
2. Use BB_SERVER_TIMEOUT = "-1" to force BitBake to remain resident - when BitBake is resident is seems to not reparse recipes. As I understand it, the recipe parse stage is when upstreams are checked for new revisions. Not sure if this would work.
3. Somehow use the locked siggens.

Is anything like this possible?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180511/13c2de83/attachment-0002.html>

More information about the Openembedded-core mailing list