[bitbake-devel] RFC: exposing information about the SRC_URI(s)/branch via buildhistory (or similar mechanism)

[Alexander Kanavin]

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 <
bitbake-devel at lists.openembedded.org> 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
> bitbake-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/bitbake-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/bitbake-devel/attachments/20190801/9786acea/attachment.html>