BitBake Apache License and Packaging for OpenBMC Components

[Andrew Jeffery]

On Wed, 18 Sep 2019, at 22:31, Andrew Geissler wrote:
> On Tue, Sep 17, 2019 at 6:59 PM Andrew Jeffery <andrew at aj.id.au> wrote:
> >
> >
> > > (5) How should I handle being in a subdirectory of a repository? The
> > > code I’m checking in will go into openbmc-tools. How does that work for
> > > CI?
> >
> > There isn't any CI for openbmc-tools at the moment, as it was originally
> > intended as a collection of quick hacks that made people's lives easier
> > without any particular guarantees. This was done to lower the bar for
> > entry and get people contributing their scripts.
> >
> > CI is probably something we need to think about though, so I've added
> > Andrew G in To/Cc:
> 
> I know for openbmc-build-scripts I did eventually make a jenkins job
> that does basic validation of the scripts it can (building docker containers).
> We were getting some regressions which were breaking our CI so this was
> a quick way to make sure the docker containers at least built when the
> scripts were updated.
> 
> We could do something similar with this repo, even if it's just running --help
> of the tools to ensure they execute. We could get more complex and
> connect them up to a QEMU session running openbmc to validate
> more. I don't have any bandwidth to do much here though so someone
> else would need to drive it.
> 
> Would we want a run-ci.sh in each subdirectory where a tool owner
> could configure it to setup their env and run their tests? Most of the
> tools are python, is there a python CI framework we should look at?
> Maybe easier to have a master script from the root dir that runs all
> CI for all tools? Just throwing some thoughts out.

The run-ci.sh approach might not be too bad - that way the jankins
job can just run a `find . -name run-ci.sh -exec \{\}\;`, which feels
kinda horrific but doesn't need much in the way of maintenance.

Andrew