[OE-core] UNVERIFIED SENDER Re: Running BitBake multiple times without rechecking upstream AUTOREV versions

[chris.laplante at agilent.com]

Hi Richard,

That looks perfect, thanks! On a related note, it seems "bitbake --revisions-changed" is broken in Sumo:

ERROR: Command execution failed: Traceback (most recent call last):
  File "/home/laplante/yocto/sources/poky/bitbake/lib/bb/command.py", line 116, in runAsyncCommand
    commandmethod(self.cmds_async, self, options)
  File "/home/laplante/yocto/sources/poky/bitbake/lib/bb/command.py", line 723, in compareRevisions
    if bb.fetch.fetcher_compare_revisions(command.cooker.data):
TypeError: fetcher_compare_revisions() takes 0 positional arguments but 1 was given



Looks like commit 97617fd6755ffa25c058215ffb060cbb86240b44 dropped the 'd' argument from that method, but command.py was never updated to reflect that.

Shall I submit a patch to change the line to be "if bb.fetch.fetcher_compare_revisions():"  ?

Chris

-----Original Message-----
From: Richard Purdie [mailto:richard.purdie at linuxfoundation.org] 
Sent: Monday, May 14, 2018 4:20 AM
To: LAPLANTE,CHRIS (A-Little Falls,ex1) <chris.laplante at agilent.com>; openembedded-core at lists.openembedded.org
Subject: UNVERIFIED SENDER Re: [OE-core] Running BitBake multiple times without rechecking upstream AUTOREV versions

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

Cheers,

Richard