From: Erik Skultety <eskultet@redhat.com>
To: Cleber Rosa <crosa@redhat.com>
Cc: "Fam Zheng" <fam@euphon.net>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Thomas Huth" <thuth@redhat.com>,
"Daniel P . Berrangé" <berrange@redhat.com>,
"Beraldo Leal" <bleal@redhat.com>,
"Stefan Hajnoczi" <stefanha@gmail.com>,
qemu-devel@nongnu.org,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Andrea Bolognani" <abologna@redhat.com>,
"Willian Rampazzo" <wrampazz@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Eduardo Habkost" <ehabkost@redhat.com>
Subject: Re: [PATCH v4 3/4] Jobs based on custom runners: docs and gitlab-runner setup playbook
Date: Mon, 19 Oct 2020 12:26:10 +0200 [thread overview]
Message-ID: <20201019102610.GB495479@nautilus> (raw)
In-Reply-To: <20201019015003.1527746-4-crosa@redhat.com>
On Sun, Oct 18, 2020 at 09:50:02PM -0400, Cleber Rosa wrote:
> To have the jobs dispatched to custom runners, gitlab-runner must
> be installed, active as a service and properly configured. The
> variables file and playbook introduced here should help with those
> steps.
>
> The playbook introduced here covers a number of different Linux
> distributions and FreeBSD, and are intended to provide a reproducible
> environment.
>
> Signed-off-by: Cleber Rosa <crosa@redhat.com>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
In general, there's been put quite some effort into the playbooks - sorry I'm
late to the game - is there a plan to introduce QEMU as a project to lcitool?
We've taken care of most of the bits in the playbooks that are being introduced
and for the remaining ones I think it would be that big of an overhaul to do
the adjustments. One major re-factor though would IMO be to break the
dependency lcitool has on the machine naming, kind of restricting it to a
limited set of hosts and corresponding names (e.g. libvirt-fedora-32) which
makes it inconvenient to prepare physical hosts.
More comments inline...
> docs/devel/ci.rst | 63 ++++++++++++++++++++++++++
> scripts/ci/setup/.gitignore | 1 +
> scripts/ci/setup/gitlab-runner.yml | 72 ++++++++++++++++++++++++++++++
> scripts/ci/setup/vars.yml.template | 13 ++++++
> 4 files changed, 149 insertions(+)
> create mode 100644 scripts/ci/setup/.gitignore
> create mode 100644 scripts/ci/setup/gitlab-runner.yml
> create mode 100644 scripts/ci/setup/vars.yml.template
>
> diff --git a/docs/devel/ci.rst b/docs/devel/ci.rst
> index 208b5e399b..a234a5e24c 100644
> --- a/docs/devel/ci.rst
> +++ b/docs/devel/ci.rst
> @@ -84,3 +84,66 @@ To run the playbook, execute::
>
> cd scripts/ci/setup
> ansible-playbook -i inventory build-environment.yml
> +
> +gitlab-runner setup and registration
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +The gitlab-runner agent needs to be installed on each machine that
> +will run jobs. The association between a machine and a GitLab project
> +happens with a registration token. To find the registration token for
> +your repository/project, navigate on GitLab's web UI to:
> +
> + * Settings (the gears like icon), then
> + * CI/CD, then
> + * Runners, and click on the "Expand" button, then
> + * Under "Set up a specific Runner manually", look for the value under
> + "Use the following registration token during setup"
> +
> +Copy the ``scripts/ci/setup/vars.yml.template`` file to
> +``scripts/ci/setup/vars.yml``. Then, set the
> +``gitlab_runner_registration_token`` variable to the value obtained
> +earlier.
> +
> +.. note:: gitlab-runner is not available from the standard location
> + for all OS and architectures combinations. For some systems,
> + a custom build may be necessary. Some builds are avaiable
> + at https://cleber.fedorapeople.org/gitlab-runner/ and this
> + URI may be used as a value on ``vars.yml``
Yes, this can be suboptimal...Would it make sense to fall back to build the
binary of a given version from git as a fallback during this playbook if the
necessary arch version isn't provided the official way? Just an idea, I'd like
to avoid the need for you to become the maintainer of the binaries and keep up
with the releases.
> +
> +To run the playbook, execute::
> +
> + cd scripts/ci/setup
> + ansible-playbook -i inventory gitlab-runner.yml
> +
> +.. note:: there are currently limitations to gitlab-runner itself when
> + setting up a service under FreeBSD systems. You will need to
> + perform steps 4 to 10 manually, as described at
Which one of them is considered an automation problem? In lcitool we made
gitlab-runner completely automated on all distros, including FreeBSD:
4) log file permissions - you're creating the user, you can as well create the
file with correct permissions
5) ensure /usr/local/etc/rc.d exists - once you execute build-environment.yml
it will pull a bunch of dependencies which ensure the dir exists
6) gitlab_runner service script should IMO provided by this automation as a
template and install to the correct location
7) ensure the service script is executable - template module can do that
8) register the runner - you're doing that
9) enable the service - Ansible's service module is generic and supports
init/OpenRC
10) I don't see a step 10
IOW I think there should be as little manual intervention as possible and in
this case I don't think any manual steps are needed by the user.
Regards,
Erik
> + https://docs.gitlab.com/runner/install/freebsd.html
> +
> +Following the registration, it's necessary to configure the runner tags,
> +and optionally other configurations on the GitLab UI. Navigate to:
> +
> + * Settings (the gears like icon), then
> + * CI/CD, then
> + * Runners, and click on the "Expand" button, then
> + * "Runners activated for this project", then
> + * Click on the "Edit" icon (next to the "Lock" Icon)
> +
> +Under tags, add values matching the jobs a runner should run. For a
> +FreeBSD 12.1 x86_64 system, the tags should be set as::
> +
> + freebsd12.1,x86_64
> +
> +Because the job definition at ``.gitlab-ci.d/custom-runners.yml``
> +would contain::
> +
> + freebsd-12.1-x86_64-all:
> + tags:
> + - freebsd_12.1
> + - x86_64
> +
> +It's also recommended to:
> +
> + * increase the "Maximum job timeout" to something like ``2h``
> + * uncheck the "Run untagged jobs" check box
> + * give it a better Description
> diff --git a/scripts/ci/setup/.gitignore b/scripts/ci/setup/.gitignore
> new file mode 100644
> index 0000000000..f112d05dd0
> --- /dev/null
> +++ b/scripts/ci/setup/.gitignore
> @@ -0,0 +1 @@
> +vars.yml
> \ No newline at end of file
> diff --git a/scripts/ci/setup/gitlab-runner.yml b/scripts/ci/setup/gitlab-runner.yml
> new file mode 100644
> index 0000000000..c2f52dad10
> --- /dev/null
> +++ b/scripts/ci/setup/gitlab-runner.yml
> @@ -0,0 +1,72 @@
> +---
> +- name: Installation of gitlab-runner
> + hosts: all
> + vars_files:
> + - vars.yml
> + tasks:
> + - debug:
> + msg: 'Checking for a valid GitLab registration token'
> + failed_when: "gitlab_runner_registration_token == 'PLEASE_PROVIDE_A_VALID_TOKEN'"
> +
> + - name: Checks the availability of official gitlab-runner builds in the archive
> + uri:
> + url: https://s3.amazonaws.com/gitlab-runner-downloads/v{{ gitlab_runner_version }}/binaries/gitlab-runner-linux-386
> + method: HEAD
> + status_code:
> + - 200
> + - 403
Why is 403 an acceptable success status code?
> + register: gitlab_runner_available_archive
> +
> + - name: Update base url
> + set_fact:
> + gitlab_runner_base_url: https://s3.amazonaws.com/gitlab-runner-downloads/v{{ gitlab_runner_version }}/binaries/gitlab-runner-
> + when: gitlab_runner_available_archive.status == 200
> + - debug:
> + msg: Base gitlab-runner url is {{ gitlab_runner_base_url }}
> +
> + - name: Set OS name (FreeBSD)
> + set_fact:
> + gitlab_runner_os: freebsd
> + when: "ansible_facts['system'] == 'FreeBSD'"
> +
> + - name: Create a group for the gitlab-runner service
> + group:
> + name: gitlab-runner
> +
> + - name: Create a user for the gitlab-runner service
> + user:
> + user: gitlab-runner
> + group: gitlab-runner
> + comment: GitLab Runner
> + home: /home/gitlab-runner
> + shell: /bin/bash
> +
> + - name: Remove the .bash_logout file when on Ubuntu systems
> + file:
> + path: /home/gitlab-runner/.bash_logout
> + state: absent
> + when: "ansible_facts['distribution'] == 'Ubuntu'"
> +
> + - name: Downloads the matching gitlab-runner
> + get_url:
> + dest: /usr/local/bin/gitlab-runner
> + url: "{{ gitlab_runner_base_url }}{{ gitlab_runner_os }}-{{ gitlab_runner_arch }}"
> + owner: gitlab-runner
> + group: gitlab-runner
> + mode: u=rwx,g=rwx,o=rx
> +
> + - name: Register the gitlab-runner
> + command: "/usr/local/bin/gitlab-runner register --non-interactive --url {{ gitlab_runner_server_url }} --registration-token {{ gitlab_runner_registration_token }} --executor shell --description '{{ ansible_facts[\"distribution\"] }} {{ ansible_facts[\"distribution_version\"] }} {{ ansible_facts[\"architecture\"] }} ({{ ansible_facts[\"os_family\"] }})'"
> +
> + - name: Install the gitlab-runner service using its own functionality
> + command: /usr/local/bin/gitlab-runner install --user gitlab-runner --working-directory /home/gitlab-runner
> + register: gitlab_runner_install_service_result
> + failed_when: "gitlab_runner_install_service_result.rc != 0 and \"already exists\" not in gitlab_runner_install_service_result.stderr"
> + when: "ansible_facts['os_family'] != 'FreeBSD'"
> +
> + - name: Enable the gitlab-runner service
> + service:
> + name: gitlab-runner
> + state: started
> + enabled: yes
> + when: "ansible_facts['os_family'] != 'FreeBSD'"
> diff --git a/scripts/ci/setup/vars.yml.template b/scripts/ci/setup/vars.yml.template
> new file mode 100644
> index 0000000000..621435d030
> --- /dev/null
> +++ b/scripts/ci/setup/vars.yml.template
> @@ -0,0 +1,13 @@
> +# The version of the gitlab-runner to use
> +gitlab_runner_version: 13.1.1
> +# The base location of gitlab-runner binaries, this will be suffixed by $OS-$ARCH
> +gitlab_runner_base_url: https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-
> +# The URL of the gitlab server to use, usually https://gitlab.com unless you're
> +# using a private GitLab instance
> +gitlab_runner_server_url: https://gitlab.com
> +# Defaults to linux, checks can be used to change this
> +gitlab_runner_os: linux
> +# Defaults to amd64 (x86_64), checks can be used to change this
> +gitlab_runner_arch: amd64
> +# A unique token made available by GitLab to your project for registering runners
> +gitlab_runner_registration_token: PLEASE_PROVIDE_A_VALID_TOKEN
> --
> 2.25.4
>
next prev parent reply other threads:[~2020-10-19 10:33 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-19 1:49 [PATCH v4 0/4] GitLab Custom Runners and Jobs (was: QEMU Gating CI) Cleber Rosa
2020-10-19 1:50 ` [PATCH v4 1/4] Jobs based on custom runners: documentation and configuration placeholder Cleber Rosa
2020-10-21 6:45 ` Thomas Huth
2020-11-09 15:17 ` Cleber Rosa
2020-10-19 1:50 ` [PATCH v4 2/4] Jobs based on custom runners: build environment docs and playbook Cleber Rosa
2020-10-19 10:27 ` Erik Skultety
2020-10-19 20:25 ` Cleber Rosa
2020-10-20 6:18 ` Erik Skultety
2020-11-09 15:20 ` Cleber Rosa
2020-10-20 17:52 ` Andrea Bolognani
2020-11-09 16:37 ` Cleber Rosa
2020-11-10 17:27 ` Andrea Bolognani
2020-10-21 7:00 ` Thomas Huth
2020-11-09 16:39 ` Cleber Rosa
2020-10-19 1:50 ` [PATCH v4 3/4] Jobs based on custom runners: docs and gitlab-runner setup playbook Cleber Rosa
2020-10-19 10:26 ` Erik Skultety [this message]
2020-10-19 20:41 ` Cleber Rosa
2020-10-20 6:58 ` Erik Skultety
2020-10-20 8:29 ` Daniel P. Berrangé
2020-10-20 18:13 ` Andrea Bolognani
2020-10-19 20:54 ` Cleber Rosa
2020-10-20 7:00 ` Erik Skultety
2020-10-19 1:50 ` [PATCH v4 4/4] Jobs based on custom runners: add job definitions for QEMU's machines Cleber Rosa
2020-10-19 10:29 ` Daniel P. Berrangé
2020-10-19 10:42 ` Philippe Mathieu-Daudé
2020-10-19 20:17 ` Cleber Rosa
2021-01-28 11:51 ` [PATCH v4 0/4] GitLab Custom Runners and Jobs (was: QEMU Gating CI) Thomas Huth
2021-02-03 21:06 ` Cleber Rosa
2021-02-04 11:27 ` Thomas Huth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201019102610.GB495479@nautilus \
--to=eskultet@redhat.com \
--cc=abologna@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=bleal@redhat.com \
--cc=crosa@redhat.com \
--cc=ehabkost@redhat.com \
--cc=fam@euphon.net \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=thuth@redhat.com \
--cc=wainersm@redhat.com \
--cc=wrampazz@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).