qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v4 3/4] Jobs based on custom runners: docs and gitlab-runner


From: Erik Skultety
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

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
> 




reply via email to

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