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.
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. AUTOREV was never meant for the project level, it is a facility strictly for local development. Alex On Thu, 1 Aug 2019 at 18:51, chris.laplante--- via bitbake-devel < [email protected]> wrote: > Hello all, > > > > Most of my team’s closed source recipes use something like the following: > > > > SRC_URI = "git://git@host/path;protocol=ssh;branch=${BRANCH}" > > SRCREV = “${AUTOREV}” > > BRANCH ??= “master” > > > > (BRANCH is just a convention we use to make the SRC_URI branch easy to > override.) > > > > 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. > > > > I’m interesting in adding SRC_URI support to buildhistory (or a similar > mechanism), and would like to get some input. > > > > Option 1) The easiest way, I think, is to just generate SRC_URI_pn- > overrides with variable expansion. > > > > 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. > > > > Option 3) A combination of 1 and 2? > > > > Looking forward to input. > > > > Thanks, > > Chris > -- > _______________________________________________ > bitbake-devel mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/bitbake-devel >
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
