[yocto] Help With TEMPLATECONF & Automated Continuous Integration (CI)

[Thomas A. F. Thorne MEng AUS MIET]

Good morning,

I am trying to setup an automate Jenkins CI server to build an image. 
To do this I need to automate the process of setting up the Yocto work
area completely.  As part of this process I am trying to eliminate the
use of or automate the production of local.conf and bblayers.conf
files.  It is working out how to deal with the selection of layers to
include that I am having difficulty with right now. 

_TEMPLATECONF_
In the documentation I have found a reference to the .templateconf file
which can be edited to set the TEMPLATECONF variable to point at a set
of templates for the local.conf and bblayers.conf files.  I suppose I
could somehow overwrite any existing .templateconf file with my own
version copied from somewhere but that seems a little messy when all the
other files are checked out of source control and manipulated only via
bitbake.  I wonder if a TEMPLATECONF environment variable would be
picked up as that would feel a little tidier to me, I shall experiment
after lunch. 

_What I Have Working_
The top level work area is formed using the Gerrit Repo tool.  This
gives me the basic set of core layers and my proprietary layer
(imaginatively named meta-net2edge).  Jenkins is able to operate repo as
it can other SCM options. 

I think I have eliminated the need to a hand crafted local.conf file
already.  I have a proprietary Yocto Board Support Package (BSP) a
costume Image Class and a set of packagegroups added to image using
IMAGE_INSTALL.  With the target MACHINE set using an environment
variable on the call to `source oe-init-build-env` there is no need to
hand craft the local.conf. 

_General Questions_
I also feel like I may have missed some documentation or instruction
that discusses going from prototyping in local.conf and bblayers.conf to
a more formal production system that minimises their use.  The
documentation for creating BSPs is good.  The documentation for creating
distributions and feature packages is a little weak in places.  Maybe I
am wrongly expecting structure where Yocto tries to be flexible. 
Am I just overcomplicating things by trying to minimise the work any one
user or machine needs to do besides checking out the work area with repo? 
How do other people perform CI or continuous delivery for their Yocto
targets?

Any help or advice would be most gratefully received. 

Regards,

-- 
Thomas A. F. Thorne MEng. AUS MIET
*Software Engineer*

*NET2EDGE*

Tel: +44 3450 130 030 <tel:+443450130030>
Email: Thomas.Thorne at Net2Edge.com <mailto:Thomas.Thorne at Net2Edge.com>
Web: http://www.Net2Edge.com/ <http://www.Net2Edge.com>

Net2Edge Limited is a company registered in England & Wales (Company No.
2438435, VAT No. GB 537553821) Kulite House, Stroudley Road, Basingstoke
RG24 8UG. This email transmission is confidential and intended solely
for the person or organisation to whom it is addressed (i.e. the Yocto
public community mailgroupin this case). If you are not the intended
recipient, you must not copy, distribute or disseminate the information,
or take any action in reliance of it. Any views expressed in this
message are those of the individual sender, except where the sender
specifically states them to be the views of any organisation or
employer. If you have received this message in error, do not open any
attachment but please notify the sender (above) and delete this message
from your system. Please rely on your own virus check. Although all
outbound mail is checked for viruses, no responsibility is taken by the
sender for any damage rising out of any bug or virus infection.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20170712/dc17efd3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20170712/dc17efd3/attachment.pgp>