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

[Andrea Galbusera]

Il 14 mag 2018 10:20 AM, "Richard Purdie" <
richard.purdie at linuxfoundation.org> ha scritto:

On Fri, 2018-05-11 at 18:23 +0000, Chris Laplante via Openembedded-core
wrote:

> 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?

Have you tried BB_SRCREV_POLICY = "cache"?


Out of curiosity and probably unrelated to the OP's issue with images/SDK
SRCREVs consistency issue.... Could setting this variable be of any help
even for building usable eSDKs when AUTOREV is around? There's an issue in
bugzilla (don't have id at hand) dealing with eSDK / AUTOREV
incompatibility...


Cheers,

Richard

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core at lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180515/bd0b45f8/attachment-0002.html>