From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: chris.laplante@agilent.com, openembedded-core@lists.openembedded.org
Subject: Re: Running BitBake multiple times without rechecking upstream AUTOREV versions
Date: Mon, 14 May 2018 09:20:06 +0100 [thread overview]
Message-ID: <1526286006.5720.113.camel@linuxfoundation.org> (raw)
In-Reply-To: <BN6PR1201MB019576F9685E3FFFC5E183E08B9F0@BN6PR1201MB0195.namprd12.prod.outlook.com>
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
next prev parent reply other threads:[~2018-05-14 8:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-11 18:23 Running BitBake multiple times without rechecking upstream AUTOREV versions chris.laplante
2018-05-14 8:20 ` Richard Purdie [this message]
2018-05-14 13:05 ` UNVERIFIED SENDER " chris.laplante
2018-05-14 13:13 ` Richard Purdie
2018-05-15 15:43 ` Andrea Galbusera
2018-05-15 21:46 ` Andrea Galbusera
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1526286006.5720.113.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=chris.laplante@agilent.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.