Re: [PATCH v5 2/4] Jobs based on custom runners: build environment docs and playbook

[Alex Bennée]

Erik Skultety <eskultet@redhat.com> writes:

> On Tue, Feb 23, 2021 at 02:01:53PM +0000, Alex Bennée wrote:
>> 
>> Cleber Rosa <crosa@redhat.com> writes:
>> 
>> > To run basic jobs on custom runners, the environment needs to be
>> > properly set up.  The most common requirement is having the right
>> > packages installed.
>> >
>> > The playbook introduced here covers the QEMU's project s390x and
>> > aarch64 machines.  At the time this is being proposed, those machines
>> > have already had this playbook applied to them.
>> >
>> > Signed-off-by: Cleber Rosa <crosa@redhat.com>
>> > ---
>> >  docs/devel/ci.rst                      | 30 ++++++++++
>> >  scripts/ci/setup/build-environment.yml | 76 ++++++++++++++++++++++++++
>> >  scripts/ci/setup/inventory             |  1 +
>> >  3 files changed, 107 insertions(+)
>> >  create mode 100644 scripts/ci/setup/build-environment.yml
>> >  create mode 100644 scripts/ci/setup/inventory
>> >
>> > diff --git a/docs/devel/ci.rst b/docs/devel/ci.rst
>> > index 585b7bf4b8..a556558435 100644
>> > --- a/docs/devel/ci.rst
>> > +++ b/docs/devel/ci.rst
>> > @@ -26,3 +26,33 @@ gitlab-runner, is called a "custom runner".
>> >  The GitLab CI jobs definition for the custom runners are located under::
>> >  
>> >    .gitlab-ci.d/custom-runners.yml
>> > +
>> > +Machine Setup Howto
>> > +-------------------
>> > +
>> > +For all Linux based systems, the setup can be mostly automated by the
>> > +execution of two Ansible playbooks.  Start by adding your machines to
>> > +the ``inventory`` file under ``scripts/ci/setup``, such as this::
>> > +
>> > +  fully.qualified.domain
>> > +  other.machine.hostname
>> 
>> Is this really needed? Can't the host list be passed in the command
>> line? I find it off to imagine users wanting to configure whole fleets
>> of runners.
>
> Why not support both, since the playbook execution is not wrapped by anything,
> giving the option of using either and inventory or direct cmdline invocation
> seems like the proper way to do it.

Sure - and I dare say people used to managing fleets of servers will
want to do it properly but in the first instance lets provide the simple
command line option so a user can get up and running without also
ensuring files are in the correct format.

>
>> 
>> > +
>> > +You may need to set some variables in the inventory file itself.  One
>> > +very common need is to tell Ansible to use a Python 3 interpreter on
>> > +those hosts.  This would look like::
>> > +
>> > +  fully.qualified.domain ansible_python_interpreter=/usr/bin/python3
>> > +  other.machine.hostname ansible_python_interpreter=/usr/bin/python3
>> > +
>> > +Build environment
>> > +~~~~~~~~~~~~~~~~~
>> > +
>> > +The ``scripts/ci/setup/build-environment.yml`` Ansible playbook will
>> > +set up machines with the environment needed to perform builds and run
>> > +QEMU tests.  It covers a number of different Linux distributions and
>> > +FreeBSD.
>> > +
>> > +To run the playbook, execute::
>> > +
>> > +  cd scripts/ci/setup
>> > +  ansible-playbook -i inventory build-environment.yml
>> 
>> So I got somewhat there with a direct command line invocation:
>> 
>>   ansible-playbook -u root -i 192.168.122.24,192.168.122.45 
>> scripts/ci/setup/build-environment.yml -e 
>> 'ansible_python_interpreter=/usr/bin/python3'
>> 
>> although for some reason a single host -i fails...
>
> The trick is to end it with a ',' like "-i host1,"

Ahh found it thanks.

-- 
Alex Bennée