#
Verificaciones en un Pull Request

Cuando abres un pull request en 🤗 Transformers, se ejecutarán una serie de verificaciones para asegurarte de que el patch que estás agregando no rompa nada existente. Estas verificaciones son de cuatro tipos:

- pruebas regulares
- creación de la documentación
- estilo del código y documentación
- consistencia del repositorio

En este documento, intentaremos explicar cuáles son esas diferentes verificaciones y el motivo detrás de ellas, así como también cómo depurarlas localmente si una falla en tu PR.

Recuerda que todas las verificaciones requieren que tengas una instalación de desarrollo:

    pip install transformers[dev]

o una instalación editable:

    pip install -e .[dev]

del repositorio de Transformers.

##
Pruebas

Todos los procesos que comienzan con `ci/circleci: run_tests_` ejecutan partes del conjunto de pruebas de Transformers. Cada uno de esos procesos se enfoca en una parte de la biblioteca en un entorno determinado: por ejemplo, `ci/circleci: run_tests_pipelines_tf` ejecuta la prueba de pipelines en un entorno donde solo está instalado TensorFlow.

Ten en cuenta que para evitar ejecutar pruebas cuando no hay un cambio real en los módulos que estás probando, solo se ejecuta una parte del conjunto de pruebas: se ejecuta una tarea auxiliar para determinar las diferencias en la biblioteca antes y después del PR (lo que GitHub te muestra en la pestaña “Files changes”) y selecciona las pruebas afectadas por esa diferencia. Este auxiliar se puede ejecutar localmente usando:

    python utils/tests_fetcher.py

desde el directorio raiz del repositorio de Transformers. Se ejecutará lo siguiente:

1. Verificación para cada archivo en el diff si los cambios están en el código, solo en comentarios o docstrings. Solo los archivos con cambios reales de código se conservan.
2. Creación de un mapa interno que proporciona para cada archivo del código fuente de la biblioteca todos los archivos a los que impacta recursivamente. Se dice que el módulo A impacta al módulo B si el módulo B importa el módulo A. Para el impacto recursivo, necesitamos una cadena de módulos que va del módulo A al módulo B en la que cada módulo importa el anterior.
3. Aplicación de este mapa en los archivos recopilados en el paso 1, lo que nos da una lista de archivos modelo afectados por el PR.
4. Asignación de cada uno de esos archivos a sus archivos de prueba correspondientes y para obtener una la lista de pruebas a ejecutar.

Al ejecutar el script localmente, debes obtener los resultados de los pasos 1, 3 y 4 impresos y así saber qué pruebas se ejecutarán. El script también creará un archivo llamado `test_list.txt` que contiene la lista de pruebas para ejecutar, y puede ejecutarlas localmente con el siguiente comando:

    python -m pytest -n 8 --dist=loadfile -rA -s $(cat test_list.txt)

En caso de que se te escape algo, el conjunto completo de pruebas también se ejecuta a diario.

##
Creación de la documentación

El proceso `build_pr_documentation` compila y genera una vista previa de la documentación para asegurarse de que todo se vea bien una vez que se fusione tu PR. Un bot agregará un enlace para obtener una vista previa de la documentación en tu PR. Cualquier cambio que realices en el PR se actualiza automáticamente en la vista previa. Si la documentación no se genera, haz clic en Detalles junto al proceso fallido para ver dónde salió mal. A menudo, el error es tan simple como que falta un archivo en `toctree`.

Si estás interesado en compilar u obtener una vista previa de la documentación localmente, echa un vistazo al `README.md` en la carpeta `docs`.

##
Estilo de código y documentación.

El formato de código se aplica a todos los archivos fuente, los ejemplos y las pruebas utilizando `black` e `isort`. También tenemos una herramienta personalizada que se ocupa del formato de los docstrings y archivos `rst` (`utils/style_doc.py`), así como del orden de las importaciones lazy realizadas en los archivos `__init__.py` de Transformers (`utils /custom_init_isort.py`). Todo esto se puede probar ejecutando

    make style

CI verifica que se hayan aplicado dentro de la verificación `ci/circleci: check_code_quality`. También se ejecuta `flake8`, que hará una verificación básica a tu código y te hará saber si encuentra una variable no definida, o una que no se usa. Para ejecutar esa verificación localmente, usa

    make quality

Esto puede llevar mucho tiempo, así que para ejecutar lo mismo solo en los archivos que modificaste en la rama actual, ejecuta

    make fixup

Este último comando también ejecutará todas las verificaciones adicionales para la consistencia del repositorio. Echemos un vistazo a estas pruebas.

##
Consistencia del repositorio

Esta verificación reagrupa todas las pruebas para asegurarse de que tu PR deja el repositorio en buen estado, y se realiza mediante `ci/circleci: check_repository_consistency`. Puedes ejecutar localmente esta verificación ejecutando lo siguiente:

    make repo-consistency

Esta instrucción verifica que:

- Todos los objetos agregados al init están documentados (realizados por `utils/check_repo.py`)
- Todos los archivos `__init__.py` tienen el mismo contenido en sus dos secciones (realizado por `utils/check_inits.py`)
- Todo el código identificado como una copia de otro módulo es consistente con el original (realizado por `utils/check_copies.py`)
- Todas las clases de configuración tienen al menos checkpoint válido mencionado en sus docstrings (realizado por `utils/check_config_docstrings.py`)
- Las traducciones de los README y el índice del documento tienen la misma lista de modelos que el README principal (realizado por `utils/check_copies.py`)
- Las tablas generadas automaticamente en la documentación están actualizadas (realizadas por `utils/check_table.py`)
- La biblioteca tiene todos los objetos disponibles incluso si no están instaladas todas las dependencias opcionales (realizadas por `utils/check_dummies.py`)

Si esta verificación falla, los primeros dos elementos requieren una reparación manual, los últimos cuatro pueden repararse automáticamente ejecutando el comando

    make fix-copies

Las verificaciones adicionales se refieren a los PRs que agregan nuevos modelos, principalmente que:

- Todos los modelos agregados están en un Auto-mapping (realizado por `utils/check_repo.py`)
- Todos los modelos se verifican correctamente (realizados por `utils/check_repo.py`)