On Tue, May 15, 2018 at 5:43 PM, Andrea Galbusera <[email protected]> wrote: > > > Il 14 mag 2018 10:20 AM, "Richard Purdie" > <[email protected]> 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...
Here is the link to the above mentioned bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11350 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
