Erik Skultety <eskul...@redhat.com> writes:
> On Tue, Feb 23, 2021 at 02:01:53PM +0000, Alex Bennée wrote: >> >> Cleber Rosa <cr...@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 <cr...@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
