[yocto] [AB PATCH 06/27] Autobuilder.py/Buildset.py: More sane parser/UI

[Flanagan, Elizabeth]

On Thu, Mar 6, 2014 at 5:43 AM, Bryan Evenson <bevenson at melinkcorp.com> wrote:
> Beth,
>
>> -----Original Message-----
>> From: yocto-bounces at yoctoproject.org [mailto:yocto-
>> bounces at yoctoproject.org] On Behalf Of Elizabeth Flanagan
>> Sent: Wednesday, March 05, 2014 1:23 PM
>> To: yocto at yoctoproject.org
>> Subject: [yocto] [AB PATCH 06/27] Autobuilder.py/Buildset.py: More sane
>> parser/UI
>>
>> From: Beth Flanagan <elizabeth.flanagan at intel.com>
>>
>> The parser for Autobuilder.py didn't dive very deep on triggered builds. If it
>> found one, it just grabbed it's properties and then displayed them on the UI.
>> This allowed us to mix and match repos/branches/commits.
>>
>
> I'm a little unclear what functionality is being removed.  After this commit, are we still able to specify a different repo/branch/commit for each layer?

Hi Bryan,

Yes, this doesn't effect that ability. What I call "mix and match" is
what you'd see if you had a build that triggers other builds (like
nightly.conf in buildsets.master). Prior to this patch, you would be
able to set via the UI each individual repo/git hash/branch/tag that
each of the triggered builds used. So, for example, your nightly could
normally run master poky and trigger a build called nightly-next which
would default to master-next. What mix and match allowed you to do is
to override via the UI any of those repo source stamp attributes.

While that was an interesting thing, I wasn't really using it, it made
the UI clunky and tbh, the parser was garbage to begin with. I had no
ability to inherit the props of triggers of triggers, it was hard to
read, hard to grok, and really needed a rewrite. So, during that
rewrite, I ditched the "mix and match" bit, simplified the source
variables (no more triggerer_nightly_triggered_commit_foo variables ;)
) and tried to make it a bit easier to understand.

> Or was the previous functionality to mix and match repo/branch/commits within a layer?  For example, would a buildset still be able to specify the repos as follows:
>
> repos: [{'poky':
>             {'repourl':'git://git.yoctoproject.org/poky',
>              'branch':'dora'}},
>         {'meta-openembedded':
>             {'repourl':'git://git.openembedded.org/meta-openembedded',
>              'branch':'dora'}}]
>
> which have a different repository for each layer?  Or do something like:
> repos: [{'poky':
>             {'repourl':'git://git.yoctoproject.org/poky',
>              'branch':'dora'}},
>         {'meta-openembedded':
>             {'repourl':'git://git.openembedded.org/meta-openembedded',
>              'branch':'master'}}]
>
> to specify different branches for each layer?  Granted, probably not a good idea for poky and meta-openembedded, but would be necessary for private layers that don't follow the same branch naming scheme.
>

Both are perfectly legitimate and these changes don't effect that
ability at all.

> And as you had stated this is a fairly large patchset with some interface changes.  What are the plans (short-term and long-term) for the Autobuilder documentation?

It's been on the list for a while, but, to be honest, it was only a
year ago that the autobuilder refactor occurred and I wanted to see
how we'd end up using it and what changes we'd need to make before we
set things in stone. As it stands, we've made very few and minor
changes over the past 6 months to the conf format, so I feel confident
that we won't make many more major changes. The one place I see
possibly making some changes is within TriggerBuilds (which we've
already changed once). I'm not thrilled with how we're setting builder
priority and I know there is a better way to do it (prioritizeBuilders
or something?), I just haven't sat down and drawn it out yet.

>Is the plan just to update the README files, or are there plans to move toward an HTML document under http://www.yoctoproject.org/documentation?  Either way, the Autobuilder documentation is pretty sparse and as an Autobuilder user I'm willing to extend the documentation.  If there are specific sections you are looking to document first, let us know.

YES! I would love help documenting this, especially from an end user
perspective. I know how *I* use the AB but how others do is somewhat
of a black hole sometimes.

Generally, I think the most bang for the buck here is to documention:

- Quick start (how to get up and running and do basic config changes)
- buildset/*.conf documentation and config/autobuilder.conf documentation
- Buildstep class documentation
- Custom buildstep creation

With 1.6 fast approaching, I'd like to get this on the radar for 1.7.

>
> Thanks,
> Bryan

-- 
Elizabeth Flanagan
Yocto Project
Build and Release