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: Alex Bennée
Subject: Re: [PATCH v5 2/4] Jobs based on custom runners: build environment docs and playbook
Date: Tue, 23 Feb 2021 18:18:21 +0000
User-agent: mu4e 1.5.8; emacs 28.0.50

Cleber Rosa <crosa@redhat.com> writes:

> 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?

I think the command line is $LESS_STEPS for a user to follow but I'm
happy to defer to the inventory approach if it's more idiomatic. I'd
rather avoid uses having their pristine source trees being polluted with
local customisations they have to keep stashing or loosing.

>
> Regards,
> Cleber.


-- 
Alex Bennée



reply via email to

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