Roles de Prueba Estándar

El paquete standard-test-roles provee roles Ansible compartidos y scripts de inventario implementando Interfaz Prueba Estándar versión 1.1.0. Tiene soporte para diversos marcos de pruebas (como BeakerLib o Avocado) y de esta manera habilitar fácilmente las pruebas existentes en Fedora CI.

Ajuste

Paquetes

STR está disponible para Centos/RHEL desde Repositorio EPEL. Como primer paso instale todos los paquetes necesarios:

sudo dnf install fedpkg libselinux-python standard-test-roles

Puede instalar también la última versión desde el repositorio copr:

sudo dnf copr -y enable @osci/standard-test-roles
sudo dnf update standard-test-roles

Artefactos

La salida de la prueba (bien salida stdout/stderr output, archivos de registro o pantallazos) es guardada de forma predeterminada en el directorio artifacts directory. Use la variable de entorno TEST_ARTIFACTS para elegir una localización diferente si lo desea:

export TEST_ARTIFACTS=/tmp/artifacts

Limpieza de artefactos
Antes de ejecutar las pruebas asegúrese de que todos los registros /tmp/artifacts/test.* están borrados.

Inventario

Un sujeto de prueba es como llamamos a la cosa a ser probada. Para convertir a un sujeto de prueba lanzado, en un sistema instalado a probar, usamos El inventario dinámico de Ansible. Use el siguiente comando para habilitarlo:

export ANSIBLE_INVENTORY=$(test -e inventory && echo inventory || echo /usr/share/ansible/inventory)

Como puede ver por la manera es que se establece el inventario, las pruebas pueden contener su propio inventario, que define sus propias instrucciones para convertir un sujeto de prueba en uno o más sistemas comprobables.

Probando

Clásico

Usted puede llamar siempre a las pruebas localmente. Muchas pruebas modifican o cambian el sistema contra el que están corriendo, de modo que téngalo en cuenta cómo invocar a las pruebas. los siguientes ejemplos invocan pruebas contra el mismo sistema en el que se extrae el repositorio git. Abajo hay más opciones para invocar pruebas contra otros sistemas totalmente formados e integrados, como un Atomic Host o una imagen contenedor sujeto de prueba_.

Hay más de una prueba presente en paquete del repositorio git. El sistema de prueba ejecutará cada libro de jugadas que coincidan con el glob tests/tests*.yml separadamente en un entorno limpio. La mayoría de las veces se utiliza un único archivo `tests.yml`coo punto de entrada principal. Para ejecutarlo use el siguiente comando:

ansible-playbook tests.yml

Puede encontrar artefactos de salida de las pruebas en artifacts/ o o especificar un directorio concreto como este:

TEST_ARTIFACTS=/tmp/output ansible-playbook tests.yml

Usted puede filtrar que clase de pruebas están corriendo mediante el argumento --tags. Para ejecutar sólo pruebas que son adecuadas para sistemas clásicos instalados por yum o dnf puede usar un comando como:

ansible-playbook --tags=classic tests.yml

Cuando corren por un Sistema CI System las pruebas se llaman de acuerdo a Prueba Estándar de Interfaz. Mire aquí para más detalles y variables estándar de invocación.

Paquete

Cuando corre las pruebas de arriba, las pruebas asumen que el sistema a probar es el mismo que está pidiendo las pruebas. En concreto, las pruebas asumen que lo que hay que probar ya está instalado.

Un sujeto de prueba es lo que llamamos a la cosa a ser probada. Los RPMs son una clase particular de sujeto de prueba. Para convertir un sujeto de prueba en un sistema a ser lanzado e instalado usamos Inventario dinámico Ansible. Invoquemos las pruebas con un inventario y una versión específica de gzip:

curl -o gzip.rpm https://kojipkgs.fedoraproject.org//packages/gzip/1.8/2.fc26/x86_64/gzip-1.8-2.fc26.x86_64.rpm
export TEST_SUBJECTS=$PWD/gzip.rpm
ansible-playbook tests.yml

Advertirá que el RPM es instalado en un sistema comprobable antes de llamar a las pruebas. Algunas pruebas contienen su propio inventario, que sus propias instrucciones para convertir un sujeto en prueba en uno o más sistemas comprobables. Pero en este caso usamos el inventario predeterminado standard-test-roles de /usr/share/ansible/inventory para hacer esto.

Contenedor

Otro ejemplo es usar un sujeto en prueba de una imagen contenedor. Este es también un entregable completamente formado e integrado. El sujeto en prueba de nuevo representa la cosa a ser probada. Para probar contenedores hay una dependencia adicional necesaria:

sudo dnf install standard-test-roles-inventory-docker

La imagen contenedor es sacada de un registro y lanzada usando un estibador por un Inventario dinámico Ansible.

export TEST_SUBJECTS=docker:docker.io/library/fedora:27
ansible-playbook --tags=container tests.yml

Si observa de cerca advertirá que la imagen es extrae si no es ya local, lanzada como contenedor y luego se prepara para que se ejecuten las pruebas. La primera vez esto puede ser un poco más largo. No todas las pruebas son capaces de funcionar en cualquier entorno distinto de un contenedor. De hecho, para ciertas pruebas, el software a ser probado puede no estar incluido en el contenedor. Pero mucha de las pruebas para los paquetes centrales deberían trabajar aqui.

El argumento --tags filtra las pruebas que no son adecuadas para ejecutarse en un contenedor, bien porque el sistema funciona de manera diferente o los paquetes correctos no son instalables.

Vea en la sección [_debug] instrucciones sobre como acceder a un contenedor en funcionamiento y diagnosticar porque han fallado las pruebas.

Argumentos adicionales para el Estibador

Las pruebas para los contenedores se ejecutan con la ayuda de un Estibador. Los contenedores se ejecutan dentro de un contexto de seguridad predeterminado. Para más información vea https://docs.docker.com/engine/security/seccomp/Pérfiles de seguridad Seccomp para Estibadores].Es posibkes que algunas pruebas requieran privilegios adcionales. En este caso especifique los argumentos necesarios para el Estibador usando la variable de entorno TEST_DOCKER_EXTRA_ARGS. Para esto cree un archivo inventario en el directorio tests con el siguiente contenido:

#!/bin/bash
export TEST_DOCKER_EXTRA_ARGS="--security-opt seccomp:unconfined"
exec merge-standard-inventory "$@"

o

#!/bin/bash
export TEST_DOCKER_EXTRA_ARGS="--privileged"
exec merge-standard-inventory "$@"

Consulte la documentación unir inventario estándar para más detalles.

Atómico

El ejemplo anterior puede parece un poco artificial, pero el concepto de un sujeto de prueba empieza a tener más sentido cuando quieres probar una entrega completamente formada e integrada, tal como Host Atómico. La prueba asunto representa de nuevo a la cosa a ser probada. La prueba asunto dentro de este caso es una imagen QCow2. Para volver un asunto de prueba a un sistema lanzador preparado para ser probado, utilizamos Inventario dinámico Ansible.

curl -Lo /tmp/atomic.qcow2 https://getfedora.org/atomic_qcow2_latest
export TEST_SUBJECTS=/tmp/atomic.qcow2
ansible-playbook --tags=atomic tests.yml

If you watch closely you’ll see that the Atomic Host image is booted, and the tests run against the launched image. Not all tests are able to function in the somewhat different environment of Atomic Host, in fact, for certain cases, the software to be tested may not be included in the Atomic Host test subject. But most of the tests in core packages should work here.

Algunas pruebas contienen su propio inventario, eso es sus propias instrucciones para ajustar una prueba asunto a uno o más sistemas testeables. Pero en este caso utilizamos el inventario standard-test-roles predeterminado para hacer esto.

El argumento --tags filtra las pruebas que no son adecuadas para ejecutarse en un Atomic Host, bien porque el sistema funciona de manera diferente o los paquetes correctos no están disponibles en ese sistema.

Consulte la sección de [_debug] para aprender como diagnosticas por qué las pruebas fallan, y la bitácora en el Atomic Host ejecutándose.

Required Packages
are specified in tests.yml for Atomic Host, additional packages will be installed using the rpm-ostree command which is affecting the test subject (it’s similar as rebuilding an rpm package to be tested) so this should be used with caution and only when necessary. Also be aware that there are certain limitations for this approach (e.g. it’s not possible to install different version of packages that are already part of the tree).

Required Packages
Atomic Host is shipped as a base ostree image, however you can install additional packages with a help of rpm-ostree install command. Currently (10.01.2018 ) repo with additional packages is actual only for the latest base-ostree image. Consequence: tests that install additional packages for Atomic Host can fail sometimes with: error: The following base packages would be replaced: xxx Solution: make sure you have the latest Atomic Host image. Additional information you can find rpm-ostree issue 415 and a possible solution in the feature using rpm-ostree jigdo rpm-ostree issue 1081.

Depurar

Para incrementar la verborrea de salida utilice la opción -v o -vvv:

ansible-playbook --tags=container tests.yml -v

o para verborrea completa:

ansible-playbook --tags=container tests.yml -vvv

Para pruebas de depuración en un contenedor en ejecución o host atómico utilice la variable TEST_DEBUG del entorno. Tras ejecutar el desempeño, verá información de diagnóstico con una orden común para iniciar sesión.

export TEST_DEBUG=1

Para el contenedor verá la salida como esto:

DIAGNOSE: docker exec -it 56de801f0ddde36fc9770666f7be2a68f89d7f18f52b7b6fe7df7a12b193bf08 /bin/bash
DIAGNOSE: kill 18261 # cuando finalice

Para host atómico las instrucciones son un poco diferente:

DIAGNOSE: ssh -p 2222 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@127.0.0.3 # password: foobar
DIAGNOSE: export ANSIBLE_INVENTORY=/tmp/inventory-cloudxyhF2M/inventory
DIAGNOSE: kill 16611 # cuando finalice

Puede conectar ahora fácilmente utilizando estas instrucciones. Utilice la instrucción kill sugerida para finalizar la instancia en ejecución cunado termine con la investigación.

Roles

Aquí está el listado de roles actualmente admitidos para ejecución de prueba:

test-estándar-avocado

Rol para ejecutar pruebas escritas por medio del framework de pruebas Avocado

test básico estándar

Un rol simple para ejecutar script de runtest.sh. u otro script en los directorios proporcionados

test beakerlib estándar

Rol para ejecutar pruebas por medio del framework de pruebas Beakerlib, soportando todos los test de los entornos

Aún hay un listado de roles ayudantes actualmente mantenidos:

test repo estandard

Un rol para instalar paquetes desde repos yum adicionales

test rpm estándar

Un rol para instalar rpms adicional

origen test estándar

Un rol para extraer pelotas tarball de fuente más actual (con pruebas)

BeakerLib

Esto es el rol recomendado para ejecutar pruebas escritas por medio del Framework de Pruebas Beakerlib como admite todas las pruebas admitidas actualmente en los entornos (atomic, classic, container). Además admite bibliotecas beakerlib las cuales periten fácilmente reutilizar código entre múltiples pruebas.

Para utilizar este rol cree el archivo tests.yml con contenidos similares al retazo siguiente. El parámetros test incluiría el listado de directorios con sus pruebas de beakerlib.

- hosts: localhost
  etiquetas:
  - atomic
  - classic
  - container
  roles:
  - role: standard-test-beakerlib
    pruebas:
    - cmd-line-options

The required_packages parameter can be used to list additional packages that need to be installed on the system to run tests. If you have required packages correctly specified in the beakerlib test metadata (in Makefile RhtsRequires stands for hard requirements, Requires for soft requirements) it is not necessary to list them again here.

- hosts: localhost
  tags:
  - atomic
  - classic
  - container
  roles:
  - role: standard-test-beakerlib
    tests:
    - cmd-line-options
    required_packages:
    - which         # cual paquete requerido para cmd-line-options
    - rpm-build     # upstream-testsuite requiere rpmbuild command
    - libtool       # upstream-testsuite requiere libtool
    - gettext       # upstream-testsuite requiere gettext

El parámetro required_packages se hace caso omiso cuando ejecute en Atomic Host: desde ahí no hay manera de instalar paquetes adicionales dentro de ese entorno.

En vez de listados todas las pruebas manualmente para ser ejecutadas, también es posible proporcionar un filtro fmf de la manera siguiente:

- hosts: localhost
  roles:
  - role: standard-test-beakerlib
    etiquetas:
    - classic
    repositorio:
    - repo: "https://src.fedoraproject.org/tests/shell.git"
      dest: "shell"
      fmf_filter: "tier: 1"

El filtro puede utilizarse además si las pruebas están almacenadas directamente en el git:

- hosts: localhost
  roles:
  - role: standard-test-beakerlib
    tags:
    - classic
    fmf_filter: "tier: 1"

Consulte Metadatos para más información sobre pruebas de filtro en metadatos fmf.

Básico

El rol básico puede ser utilizado para ejecutar scripts o binarios como pruebas simples. Por ejemplo el archivo testsyml a continuación ejecutará binaty --help como una instrucción del intérprete en el directorio actual y proporciona permiso/fallo basándose en su código devuelto:

 - hosts: localhost
   roles:
   - role: standard-test-basic
     tags:
     - classic
     tests:
     - simple:
         dir: .
         run: binary --help

Aquí está otro ejemplo de test.yml el cual obtiene pruebas de una integración única desde un repo compartido y utiliza parametrizar para ejecutarlo múltiples veces con diferentes variables de entorno:

 - hosts: localhost
   roles:
   - role: standard-test-basic
     tags:
     - classic
     repositories:
     - repo: "https://src.fedoraproject.org/tests/python.git"
       dest: "python"
     tests:
     - smoke27:
         dir: python/smoke
         run: VERSION=2.7 METHOD=virtualenv ./venv.sh
     - smoke37:
         dir: python/smoke
         run: VERSION=3.7 ./venv.sh
     required_packages:
     - python27
     - python37
     - python2-virtualenv
     - python3-virtualenv
     - python2-devel
     - python3-devel

RHTS

Este rol ha sido obsoleto por el rol BeakerLib el cual proporciona funcionalidad similar.

Más

Enlaces

Repositorios Pagure y Copr:

Contacto

  • Andrei Stepanov (astepano)

  • Miroslav Vadkerti (mvadkert)

Want to help? Learn how to contribute to Fedora Docs ›