qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Cleber Rosa
Subject: Re: [PATCH v5 2/4] Jobs based on custom runners: build environment docs and playbook
Date: Tue, 23 Feb 2021 12:23:40 -0500

On Tue, Feb 23, 2021 at 03:17:24PM +0000, Alex Bennée wrote:
> 
> 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.
>

Like I said before, I'm strongly in favor of a more straightforward
documentation, instead of documenting multiple ways to perform the
same task.  I clearly believe that writing the inventory file (which
will later be used for the second gitlab-runner playbook) is the best
choice here.

Do you think the command line approach is clearer?  Should we switch?

Regards,
Cleber.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]