<div dir="ltr"><div>Apologies, but I think you should drop the practice of using AUTOREV. This completely destroys reproducibility of builds, and makes them susceptible to global breakage when someone pushes a broken commit into one of the component repositories. </div><br><div>Yes, bumping SRCREV is annoying, but a) it can be automated; b) you can catch and reject any problems with the build at that point, so you always have a nightly that works.</div><div><br></div><div>AUTOREV was never meant for the project level, it is a facility strictly for local development.<br></div><div><br></div><div>Alex<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 1 Aug 2019 at 18:51, chris.laplante--- via bitbake-devel <<a href="mailto:bitbake-devel@lists.openembedded.org">bitbake-devel@lists.openembedded.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div class="gmail-m_-1566771397637526125WordSection1">
<p class="MsoNormal">Hello all,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Most of my team’s closed source recipes use something like the following:
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-left:0.5in">SRC_URI = "git://git@host/path;protocol=ssh;branch=${BRANCH}"<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:0.5in">SRCREV = “${AUTOREV}”<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:0.5in">BRANCH ??= “master”<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">(BRANCH is just a convention we use to make the SRC_URI branch easy to override.)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">This makes nightly builds convenient because we always build from the latest. For release versions, we can use SRCREV_pn-recipe and/or BRANCH_pn-recipe overrides in local.conf. We get the SRCREV overrides using buildhistory-collect-srcrevs.
But buildhistory has no notion or tracking of SRC_URI or branches, so currently we use a script that generates the BRANCH overrides.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I’m interesting in adding SRC_URI support to buildhistory (or a similar mechanism), and would like to get some input.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Option 1) The easiest way, I think, is to just generate SRC_URI_pn- overrides with variable expansion.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Option 2) I think it could be useful to introduce BRANCH as a convention. Currently the “branch” SRC_URI parameter implicitly defaults to “master”. I could foresee it implicitly defaulting to “${BRANCH}”, with BRANCH ??= “master” to replicate
existing functionality. To handle multiple source-controlled SRC_URIs, we’d have to do something similar to how SRCREV has a “name” override. With this option, I wouldn’t think it would be necessary to generate SRC_URI overrides; just BRANCH overrides.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Option 3) A combination of 1 and 2?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Looking forward to input.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
<p class="MsoNormal">Chris<u></u><u></u></p>
</div>
</div>
-- <br>
_______________________________________________<br>
bitbake-devel mailing list<br>
<a href="mailto:bitbake-devel@lists.openembedded.org" target="_blank">bitbake-devel@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/bitbake-devel" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/bitbake-devel</a><br>
</blockquote></div>