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

[Mark Hatle]

On 8/1/19 11:51 AM, chris.laplante--- via bitbake-devel 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?
> 

I've had some thoughts of capturing that same information, as well as
automatically generating a changelog (from short-commit entries) from the last
build to the current one use standard git commands... but I've never had time to
implement anything.

When I talked with RP about this a while back, he mentioned it should be
possible to extend the functionality of buildhistory with an additional class.
So the user could opt into extended functionality by including more then one
buildhistory class.

So my recommendation, store the URL you pulled from along with the SRCREV (if
it's not already been stored).  This can then be used later to investigate -- or
extended [internally or externally] to create changelogs.

--Mark

> 
> Looking forward to input.
> 
>  
> 
> Thanks,
> 
> Chris
> 
>