Re: [OE-core] RFC: exposing information about the SRC_URI(s)/branch via buildhistory (or similar mechanism)
> > I've patched our tree so that SRC_URI, LICENSE and CVE_PRODUCT are > > archived in buildhistory. SRC_URI has many uses and changes and > > patches can be easily identified. Same with LICENSE, any changes > > trigger a review. CVE_PRODUCT is exported so that we can do QA check > > to make sure mapping from CVE_PRODUCT for non CLOSED licenses exists > > to NVD database product names (maintaining a white list of recipes > > which don't have any CVEs yet). > > I think this supports my point about being more interested in patches > allowing people to extend/customise buildhistory than just adding X. > > Whilst we want to have good defaults, there are always going to be > niche cases for people wanting to extend it... Agreed. Then we can implement our BRANCH scheme without polluting the core code with it. Chris -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: exposing information about the SRC_URI(s)/branch via buildhistory (or similar mechanism)
On Fri, 2019-08-02 at 07:37 +, mikko.rap...@bmw.de wrote: > Hi, > > On Thu, Aug 01, 2019 at 04:51:38PM +, chris.laplante--- via > Openembedded-core wrote: > > > I'm interesting in adding SRC_URI support to buildhistory (or a > > similar mechanism), and would like to get some input. > > Yes to this. > > Also would be nice if there was an easy way to add bitbake variables > to buildhistory. > > I've patched our tree so that SRC_URI, LICENSE and CVE_PRODUCT are > archived in buildhistory. SRC_URI has many uses and changes and > patches can be easily identified. Same with LICENSE, any changes > trigger a review. CVE_PRODUCT is exported so that we can do QA check > to make sure mapping from CVE_PRODUCT for non CLOSED licenses exists > to NVD database product names (maintaining a white list of recipes > which don't have any CVEs yet). I think this supports my point about being more interested in patches allowing people to extend/customise buildhistory than just adding X. Whilst we want to have good defaults, there are always going to be niche cases for people wanting to extend it... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: exposing information about the SRC_URI(s)/branch via buildhistory (or similar mechanism)
> I'd be curious to see the patches. > It's definitely something we could use here; we used to have nightly > build checking the build using AUTOREV as well. > > On Fri, Aug 2, 2019 at 3:43 AM wrote: > > > > Hi, > > > > On Thu, Aug 01, 2019 at 04:51:38PM +, chris.laplante--- via > > Openembedded-core wrote: > > > > > I'm interesting in adding SRC_URI support to buildhistory (or a similar > > > mechanism), and would like to get some input. > > > > Yes to this. > > > > Also would be nice if there was an easy way to add bitbake variables to > > buildhistory. > > > > I've patched our tree so that SRC_URI, LICENSE and CVE_PRODUCT are archived > > in buildhistory. SRC_URI has many uses and changes and patches can > > be easily identified. Same with LICENSE, any changes trigger a review. > > CVE_PRODUCT is exported so that we can do QA check to make sure mapping > > from CVE_PRODUCT for non CLOSED licenses exists to NVD database product > > names (maintaining a white list of recipes which don't have any CVEs yet). > > > > We've also changed the SDK name to be stable across builds and added > > DISTRO to the path. In our case IMAGE_NAME and SDK_NAME will include > > git tree tag and hash if tree is dirty, which changes buildhistory SDK paths > > for every build with different input. > > > > I could submit the patches if there is interest in them. I like the idea of including LICENSE and CVE_PRODUCT as well. I will look into to making it extensible via a variable, e.g. BUILDHISTORY_PACKAGE_EXTRA_VARIABLES or something. Chris -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: exposing information about the SRC_URI(s)/branch via buildhistory (or similar mechanism)
I'd be curious to see the patches. It's definitely something we could use here; we used to have nightly build checking the build using AUTOREV as well. On Fri, Aug 2, 2019 at 3:43 AM wrote: > > Hi, > > On Thu, Aug 01, 2019 at 04:51:38PM +, chris.laplante--- via > Openembedded-core wrote: > > > I'm interesting in adding SRC_URI support to buildhistory (or a similar > > mechanism), and would like to get some input. > > Yes to this. > > Also would be nice if there was an easy way to add bitbake variables to > buildhistory. > > I've patched our tree so that SRC_URI, LICENSE and CVE_PRODUCT are archived > in buildhistory. SRC_URI has many uses and changes and patches can > be easily identified. Same with LICENSE, any changes trigger a review. > CVE_PRODUCT is exported so that we can do QA check to make sure mapping > from CVE_PRODUCT for non CLOSED licenses exists to NVD database product > names (maintaining a white list of recipes which don't have any CVEs yet). > > We've also changed the SDK name to be stable across builds and added > DISTRO to the path. In our case IMAGE_NAME and SDK_NAME will include > git tree tag and hash if tree is dirty, which changes buildhistory SDK paths > for every build with different input. > > I could submit the patches if there is interest in them. > > Cheers, > > -Mikko > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: exposing information about the SRC_URI(s)/branch via buildhistory (or similar mechanism)
Hi, On Thu, Aug 01, 2019 at 04:51:38PM +, chris.laplante--- via Openembedded-core wrote: > I'm interesting in adding SRC_URI support to buildhistory (or a similar > mechanism), and would like to get some input. Yes to this. Also would be nice if there was an easy way to add bitbake variables to buildhistory. I've patched our tree so that SRC_URI, LICENSE and CVE_PRODUCT are archived in buildhistory. SRC_URI has many uses and changes and patches can be easily identified. Same with LICENSE, any changes trigger a review. CVE_PRODUCT is exported so that we can do QA check to make sure mapping from CVE_PRODUCT for non CLOSED licenses exists to NVD database product names (maintaining a white list of recipes which don't have any CVEs yet). We've also changed the SDK name to be stable across builds and added DISTRO to the path. In our case IMAGE_NAME and SDK_NAME will include git tree tag and hash if tree is dirty, which changes buildhistory SDK paths for every build with different input. I could submit the patches if there is interest in them. Cheers, -Mikko -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] RFC: exposing information about the SRC_URI(s)/branch via buildhistory (or similar mechanism)
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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
