• Tipos de corredores
  • Corredores compartidos
    • Cómo los corredores compartidos eligen trabajos
    • Habilitar corredores compartidos
    • Deshabilitar corredores compartidos
  • Corredores de grupo
    • Crear un corredor de grupo
    • Ver y administrar corredores de grupo
    • Pausar o eliminar un corredor de grupo
  • Corredores específicos
    • Crear un corredor específico
    • Habilitar un corredor específico para un proyecto específico
    • Evitar que un corredor específico se habilite para otros proyectos
• Borrar manualmente la caché del corredor
• Establecer el tiempo de espera máximo del trabajo para un corredor
• Tenga cuidado con la información confidencial
  • Evitar que los corredores revelen información confidencial
  • Bifurcaciones
  • Vectores de ataque en corredores
  • Restablecer el token de registro de corredor para un proyecto
• Determinar la dirección IP de un corredor
  • Determinar la dirección IP de un corredor compartido
  • Determinar la dirección IP de un corredor específico
• Utilizar etiquetas para limitar el número de trabajos que utilizan el corredor
  • runner ejecuta solo trabajos etiquetados
  • runner puede ejecutar trabajos sin etiquetar
• Configurar el comportamiento del runner con variables
  • Estrategia de Git
  • Estrategia de submódulos de Git
  • Comprobación de Git
  • Banderas git limpias
  • Clonación superficial
  • Directorios de compilación personalizados
    • Gestionar la concurrencia
    • Rutas anidadas
  • Intentos de etapas de trabajo
• Las llamadas al sistema no están disponibles en GitLab.com runners compartidos
• Configuración de artefactos y caché

En GitLab CI/CD, los runners ejecutan el código definido en .gitlab-ci.yml.Un runner es un agente ligero y altamente escalable que recoge un trabajo de CI a través de la API de coordinador de GitLab CI/CD, ejecuta el trabajo y envía el resultado a la instancia de GitLab.Los runners

son creados por un administrador y están visibles en la interfaz de USUARIO de GitLab.Los corredores pueden ser específicos para ciertos proyectos o estar disponibles para todos los proyectos.

Esta documentación se centra en el uso de corredores en GitLab.Si necesita instalar y configurar GitLab Runner, consulte la documentación de GitLab Runner.

Tipos de corredores

En la interfaz de usuario de GitLab hay tres tipos de corredores, según a quién quieras tener acceso:

• Los corredores compartidos están disponibles para todos los grupos y proyectos en una instancia de GitLab.
• Los corredores de grupo están disponibles para todos los proyectos y subgrupos de un grupo.
• Los corredores específicos están asociados con proyectos específicos.Por lo general, se utilizan corredores específicos para un proyecto a la vez.

Corredores compartidos

Los corredores compartidos están disponibles para cada proyecto en una instancia de GitLab.

Use corredores compartidos cuando tenga varios trabajos con requisitos similares. En lugar de tener varios corredores en ralentí para muchos proyectos, puede tener algunos corredores que manejan múltiples proyectos.

Si utiliza una instancia autogestionada de GitLab:

• Su administrador puede instalar y registrar corredores compartidos yendo a la configuración de su proyecto > CI / CD, ampliando la sección de corredores y haciendo clic en Mostrar instrucciones de instalación de corredores.Estas instrucciones también están disponibles en la documentación.
• El administrador también puede configurar un número máximo de minutos de canalización de runner compartidos para cada grupo.

Si está utilizando GitLab.com:

• Puede seleccionar de una lista de corredores compartidos que mantiene GitLab.
• Los corredores compartidos consumen los minutos de canalización incluidos en tu cuenta.

Cómo los corredores compartidos seleccionan trabajos

Los corredores compartidos procesan los trabajos utilizando una cola de uso justo. Esta cola evita que los proyectos creen cientos de trabajos y utilicen todos los recursos de runner compartidos disponibles.

El algoritmo de cola de uso razonable asigna trabajos en función de los proyectos que tienen el menor número de trabajos que ya se están ejecutando en corredores compartidos.

Ejemplo 1

Si estos trabajos están en la cola:

• Trabajo 1 para el Proyecto 1
• Trabajo 2 para el Proyecto 1
• Trabajo 3 para el Proyecto 1
• Trabajo 4 para el Proyecto 2
• Trabajo 5 para el Proyecto 2
• Trabajo 6 para el Proyecto 3

Ejemplo 2

Si estos trabajos están en la cola:

• Trabajo 1 para el Proyecto 1
• Trabajo 2 para el Proyecto 1
• Trabajo 3 para el Proyecto 1
• Trabajo 4 para el Proyecto 2
• Trabajo 5 para el Proyecto 2
• Trabajo 6 para el Proyecto 3

p>

1. El trabajo 1 se elige primero, porque tiene el número de trabajos más bajo de los proyectos sin trabajos en ejecución (es decir, todos los proyectos).
2. Terminamos el trabajo 1.
3. El trabajo 2 es el siguiente, ya que, una vez finalizado el trabajo 1, todos los proyectos tienen 0 trabajos en ejecución de nuevo, y 2 es el número de trabajo disponible más bajo.
4. El trabajo 4 es el siguiente, porque con el Proyecto 1 ejecutando un trabajo, 4 es el número más bajo de proyectos que no ejecutan trabajos (Proyectos 2 y 3).
5. Terminamos el trabajo 4.
6. El trabajo 5 es el siguiente, porque al terminar el trabajo 4, el Proyecto 2 no tiene trabajos en ejecución de nuevo.
7. El trabajo 6 es el siguiente, porque el Proyecto 3 es el único proyecto que queda sin trabajos en ejecución.
8. Por último, elegimos el trabajo 3 because porque, de nuevo, es el único trabajo que queda.

Habilitar corredores compartidos

Activado GitLab.com, los corredores compartidos están habilitados en todos los proyectos por defecto.

En las instancias autogestionadas de GitLab, un administrador debe instalarlas y registrarlas.

También puede habilitar corredores compartidos para proyectos individuales.

Para habilitar corredores compartidos:

1. Vaya a la configuración del proyecto > CI / CD y expanda la sección de corredores.
2. Seleccione Habilitar corredores compartidos para este proyecto.

Deshabilitar corredores compartidos

Puede deshabilitar corredores compartidos para proyectos individuales o para grupos.Debe tener permisos de propietario para el proyecto o grupo.

Para deshabilitar corredores compartidos para un proyecto:

1. Vaya a la configuración del proyecto > CI / CD y expanda la sección de corredores.
2. En el área Corredores compartidos, seleccione Habilitar corredores compartidos para este proyecto para que el conmutador esté en gris.

Los corredores compartidos se deshabilitan automáticamente para un proyecto:

• Si la configuración de corredores compartidos para el grupo principal está deshabilitada, y
• Si no se permite anular esta configuración a nivel de proyecto.

Para deshabilitar corredores compartidos para un grupo:

1. Vaya a la configuración del grupo> CI / CD y expanda la sección de corredores.
2. En el área Corredores compartidos, desactive la opción Habilitar corredores compartidos para este grupo.
3. Opcionalmente,para permitir que se habiliten corredores compartidos para proyectos o subgrupos individuales, haga clic en Permitir proyectos y subgrupos para anular la configuración de grupo.

Corredores de grupo

Utilice corredores de grupo cuando desee que todos los proyectos de un grupo tengan acceso a un conjunto de corredores.

Los corredores de grupo procesan los trabajos utilizando una cola de entrada y salida (FIFO).

Crear un corredor de grupo

Puede crear un corredor de grupo para su instancia de GitLab autogestionada o para GitLab. com. Debe tener permisos de propietario para el grupo.

Para crear un runner de grupo:

1. Instale GitLab Runner.
2. Vaya al grupo para el que desea que el corredor trabaje.
3. Vaya a Configuración > CI / CD y expanda la sección de Corredores.
4. Anote la URL y el token.
5. Registra el corredor.

Ver y administrar corredores de grupo

Puede ver y administrar todos los corredores de un grupo, sus subgrupos y proyectos.Puede hacer esto para su instancia de GitLab autogestionada o para GitLab.com.Debe tener permisos de propietario para el grupo.

1. Vaya al grupo donde desea ver a los corredores.
2. Vaya a Configuración > CI / CD y expanda la sección de Corredores.

3. Se muestran los siguientes campos.

   Atributo	Descripción
   Tipo	Uno o más de los siguientes estados: compartida, grupo específico, bloqueado, o en pausa
   Corredor token	símbolo usado para identificar el corredor, y que el corredor se utiliza para comunicarse con GitLab ejemplo
   Descripción	Descripción dada para el corredor cuando fue creado
   Versión	GitLab Finalista de la versión
   dirección IP	Dirección IP del host en el que el corredor está registrado
   Proyectos	El recuento de los proyectos a los que el corredor se le asigna
   Empleo	Total de la ejecución de los trabajos por el corredor
   Etiquetas	Etiquetas asociadas con el corredor
   Último contacto	marca de tiempo que indica cuando el GitLab instancia última contactado con el corredor

Desde esta página, usted puede modificar, detener y eliminar los corredores del grupo, sus subgrupos, y proyectos.

Pausar o quitar un corredor de grupo

Puede pausar o quitar un corredor de grupo para su instancia de GitLab autogestionada o para GitLab.com.Debe tener permisos de propietario para el grupo.

1. Vaya al grupo para el que desea eliminar o pausar el corredor.
2. Vaya a Configuración > CI / CD y expanda la sección de Corredores.
3. Haga clic en Pausar o Quitar corredor.
   • Si pausa un corredor de grupo que es utilizado por varios proyectos, el corredor se detiene para todos los proyectos.
   • En la vista de grupo, no se puede quitar un runner asignado a más de un proyecto.Primero debes eliminarlo de cada proyecto.
4. En el cuadro de diálogo de confirmación, haga clic en Aceptar.

Corredores específicos

Utilice corredores específicos cuando desee utilizar corredores para proyectos específicos. Por ejemplo, cuando tiene:

• Trabajos con requisitos específicos, como un trabajo de implementación que requiere credenciales.
• Proyectos con mucha actividad de IC que pueden beneficiarse de estar separados de otros corredores.

Puede configurar un corredor específico para que lo usen varios proyectos. Los ejecutores específicos deben habilitarse explícitamente para cada proyecto.

Los corredores específicos procesan los trabajos utilizando una cola FIFO (primero en entrar, primero en salir).

Crear un runner específico

Puede crear un runner específico para su instancia de GitLab autogestionada o para GitLab. com. Debe tener permisos de propietario para el proyecto.

Para crear un runner específico:

1. Instalar runner.
2. Vaya a la configuración del proyecto > CI / CD y expanda la sección Runners.
3. Anote la URL y el token.
4. Registra el corredor.

Habilitar un corredor específico para un proyecto específico

Un corredor específico está disponible en el proyecto para el que se creó. Un administrador puede habilitar un corredor específico para aplicar a proyectos adicionales.

• debe tener permisos de Propietario para el proyecto.
• El corredor específico no debe estar bloqueado.

Para habilitar o deshabilitar un corredor específico para un proyecto:

1. Vaya a la configuración del proyecto > CI / CD y expanda la sección de corredores.
2. haga Clic en Habilitar para este proyecto o Deshabilitar para este proyecto.

Evitar que se habilite un corredor específico para otros proyectos

Puede configurar un corredor específico para que esté «bloqueado» y no se pueda habilitar para otros proyectos.Esta configuración se puede habilitar la primera vez que registra un corredor,pero también se puede cambiar más adelante.

Para bloquear o desbloquear un corredor:

1. Vaya a la configuración del proyecto > CI/CD y expanda la sección de corredores.
2. Encuentra el corredor que quieres bloquear o desbloquear. Asegúrate de que esté activado.
3. Haga clic en el botón lápiz.
4. Marque la opción Bloquear proyectos actuales.
5. haga Clic en Guardar cambios.

Borrar manualmente la caché de runner

Leer borrar la caché.

Establecer el tiempo de espera máximo del trabajo para un corredor

Para cada corredor, puede especificar un tiempo de espera máximo del trabajo. Este tiempo de espera,si es más pequeño que el tiempo de espera definido por el proyecto, tiene prioridad.

Esta función se puede utilizar para evitar que su runner compartido se vea abrumado por un proyecto que tiene trabajos con un tiempo de espera prolongado (por ejemplo, una semana).

Cuando no está configurado, los corredores no anulan el tiempo de espera del proyecto.

En GitLab.com, no puede anular el tiempo de espera del trabajo para corredores compartidos y debe usar el tiempo de espera definido por el proyecto.

Para establecer el tiempo de espera máximo del trabajo:

1. En un proyecto, vaya a Ajustes > CI/CD > Runners.
2. Seleccione su corredor específico para editar la configuración.
3. Introduzca un valor en Tiempo de espera máximo del trabajo.
4. Seleccione Guardar cambios.

Cómo funciona esta función:

Ejemplo 1 – Tiempo de espera del Runner mayor que el tiempo de espera del proyecto

1. Se establece el tiempo de espera máximo del trabajo para un runner en 24 horas
2. Se establece el tiempo de espera de CI/CD para un proyecto en 2 horas
3. Se inicia un trabajo
4. El trabajo, si se ejecuta más tiempo, se agota después de 2 horas

Ejemplo 2 – Tiempo de espera del Runner configuración de tiempo de espera de trabajo desde un runner

Ejemplo 3 – Runner tiempo de espera más pequeño que el tiempo de espera del proyecto

1. Se establece el tiempo de espera máximo del trabajo para un runner en 30 minutos
2. Se establece el tiempo de espera de CI/CD para un proyecto en 2 horas
3. Se inicia un trabajo
4. El trabajo, si se ejecuta más tiempo, se agota después de 30 minutos

Tenga cuidado con la información confidencial

Con algunos ejecutores de runner,si puede ejecutar un trabajo en el runner, puede obtenga acceso completo al sistema de archivos y,por lo tanto, a cualquier código que ejecute, así como al token del runner. Con los corredores compartidos, esto significa que cualquiera que ejecute trabajos en el corredor, puede acceder al código de cualquier otra persona que se ejecute en el corredor.

Además, como puede obtener acceso al token de runner, es posible crear un clon de un runner y enviar trabajos falsos, por ejemplo.

Lo anterior se evita fácilmente restringiendo el uso de ejecutores compartidos en grandes instancias públicas de GitLab, controlando el acceso a su instancia de GitLab y utilizando ejecutores de ejecución más seguros.

Evite que los corredores revelen información sensible

Puede proteger a los corredores para que no revelen información confidencial.Cuando un corredor está protegido, el corredor selecciona trabajos creados solo en ramas protegidas o etiquetas protegidas e ignora otros trabajos.

Para proteger o desproteger un corredor:

1. Vaya a la configuración del proyecto > CI/CD y expanda la sección de corredores.
2. Encuentre el corredor que desea proteger o desproteger. Asegúrate de que esté activado.
3. Haga clic en el botón lápiz.
4. Marque la opción Protegida.
5. haga Clic en Guardar cambios.

Bifurcaciones

Cada vez que se bifurca un proyecto, copia la configuración de los trabajos relacionados con él. Esto significa que si tienes corredores compartidos configurados para un proyecto y alguien se bifurca en ese proyecto, los corredores compartidos sirven trabajos de este proyecto.

Vectores de ataque en corredores

Mencionados brevemente anteriormente, pero las siguientes cosas de corredores pueden ser explotadas.Siempre estamos buscando contribuciones que puedan mitigar estas consideraciones de seguridad.

Restablecer el token de registro de runner para un proyecto

Si cree que se reveló un token de registro para un proyecto, debe volver a configurarlo. Se puede usar un token para registrar a otro corredor para el proyecto. Ese nuevo runner puede ser usado para obtener los valores de variables secretas o para clonar código de proyecto.

Para restablecer el token:

1. Vaya a la configuración del proyecto > CI / CD.
2. Expanda la sección Configuración general de canalizaciones.
3. Busque el campo de formulario de token de corredor y haga clic en el botón Revelar valor.
4. Borre el valor y guarde el formulario.
5. Después de actualizar la página, expanda la sección Configuración de corredores y compruebe el token de registro, que debe cambiarse.

A partir de ahora, el token antiguo ya no es válido y no registra ningún corredor nuevo en el proyecto. Si está utilizando alguna herramienta para aprovisionar y registrar nuevos corredores, los tokens utilizados en esas herramientas deben actualizarse para reflejar el valor del nuevo token.

Determine la dirección IP de un runner

Puede ser útil conocer la dirección IP de un corredor para que pueda solucionar problemas con ese corredor. GitLab almacena y muestra la dirección IP al ver el origen de las solicitudes HTTP que realiza a GitLab al sondear trabajos. La dirección IP siempre se mantiene actualizada, por lo que si la IP del corredor cambia, se actualiza automáticamente en GitLab.

La dirección IP para corredores compartidos y corredores específicos se puede encontrar en lugares indiferentes.

Determinar la dirección IP de un runner compartido

Para ver la dirección IP de un runner compartido, debe tener acceso de administrador a la instancia de GitLab. Para determinar esto:

1. Visite el Área de administración > Vista general > Corredores.
2. Busque el corredor en la tabla y debería ver una columna para la dirección IP.

Determine la dirección IP de un corredor específico

Para poder encontrar la dirección IP de un corredor para un proyecto específico,debe tener permisos de propietario para el proyecto.

1. Vaya a la configuración del proyecto > CI / CD y expanda la sección Runners.
2. En la página de detalles, debería ver una fila para la dirección IP.

Use etiquetas para limitar el número de trabajos utilizando el corredor

Debe configurar un corredor para poder ejecutar todos los diferentes tipos de trabajos que puede encontrar en los proyectos sobre los que se comparte. Esto sería problemático para grandes cantidades de proyectos, si no fuera por las etiquetas.

Las etiquetas GitLab CI no son lo mismo que las etiquetas Git. Las etiquetas GitLab CI están asociadas a los corredores.Las etiquetas Git están asociadas con las confirmaciones.

Al etiquetar a un corredor para los tipos de trabajos que puede manejar, puede hacer que los corredores sureshared solo ejecuten los trabajos para los que están equipados.

Por ejemplo, en GitLab tenemos corredores etiquetados con rails si contienen las dependencias apropiadas para ejecutar conjuntos de pruebas de Rails.

Cuando se registra un corredor, su comportamiento predeterminado es solo marcar con picktag jobs.To cambie esto, debe tener permisos de propietario para el proyecto.

Para hacer que un corredor elija trabajos sin etiquetar:

1. Vaya a la configuración del proyecto > CI / CD y expanda la sección Runners.
2. Encuentre el corredor que desea seleccionar trabajos sin etiquetar y asegúrese de que esté habilitado.
3. Haga clic en el botón lápiz.
4. Marque la opción Ejecutar trabajos sin etiquetar.
5. Haga clic en el botón Guardar cambios para que los cambios surtan efecto.

A continuación se muestran algunos escenarios de ejemplo de diferentes variaciones.

runner ejecuta solo trabajos etiquetados

Los siguientes ejemplos ilustran el impacto potencial de que el runner esté configurado para ejecutar solo trabajos etiquetados.

Ejemplo 1:

1. El runner está configurado para ejecutar solo trabajos etiquetados y tiene la etiqueta docker.
2. Un trabajo que tiene una etiqueta hello se ejecuta y se pega.

Ejemplo 2:

1. El runner está configurado para ejecutar solo trabajos etiquetados y tiene la etiqueta docker.
2. Se ejecuta y ejecuta un trabajo que tiene una etiqueta docker.

Ejemplo 3:

1. El runner está configurado para ejecutar solo trabajos etiquetados y tiene la etiqueta docker.
2. Un trabajo que no tiene etiquetas definidas se ejecuta y se pega.

el corredor puede ejecutar trabajos sin etiquetar

Los siguientes ejemplos ilustran el impacto potencial de que el corredor esté configurado para ejecutar trabajos etiquetados y sin etiquetar.

Ejemplo 1:

1. El runner está configurado para ejecutar trabajos sin etiquetar y tiene la etiqueta docker.
2. Se ejecuta y ejecuta un trabajo que no tiene etiquetas definidas.
3. Se ejecuta y ejecuta un segundo trabajo que tiene definida la etiqueta docker.

Ejemplo 2:

1. El runner está configurado para ejecutar trabajos sin etiquetar y no tiene etiquetas definidas.
2. Se ejecuta y ejecuta un trabajo que no tiene etiquetas definidas.
3. Un segundo trabajo que tiene definida la etiqueta docker está atascado.

Configurar el comportamiento del corredor con variables

Puede usar variables CI / CD para configurar el comportamiento de Git del corredor de forma móvil o para trabajos individuales:

• GIT_STRATEGY
• GIT_SUBMODULE_STRATEGY
• GIT_CHECKOUT
• GIT_CLEAN_FLAGS
• GIT_FETCH_EXTRA_FLAGS
• GIT_DEPTH (superficial de la clonación)
• GIT_CLONE_PATH (custom directorios de compilación)

también puede utilizar variables para configurar cuántas veces un runnerattempts ciertas etapas de la ejecución del trabajo.

Estrategia de Git

Usted puede establecer el GIT_STRATEGY utiliza para recuperar el contenido del repositorio, eitherglobally o por trabajo en el variables sección:

variables: GIT_STRATEGY: clone

Hay tres valores posibles: clonefetch y none. Si no se especifica,los trabajos utilizan la configuración de canalización del proyecto.

clone es la opción más lenta. Clona el repositorio desde cero para cada trabajo, asegurando que la copia local de trabajo esté siempre prístina.Si se encuentra un árbol de trabajo existente, se elimina antes de clonar.

fetch es más rápido ya que re-utiliza la copia de trabajo local (cayendo a clonesi no existe). git clean se usa para deshacer cualquier cambio realizado por el último trabajo, y git fetch se usa para recuperar confirmaciones realizadas después de que se ejecutara el último trabajo.

Sin embargo, fetch requiere acceso al árbol de trabajo anterior. Esto funciona bien cuando se usa el ejecutor shell o docker porque la precisión para preservar los árboles de trabajo y tratar de reutilizarlos de forma predeterminada.

Esto tiene limitaciones cuando se utiliza el ejecutor de máquina de Docker.

No funciona para el ejecutor kubernetes, pero existe una propuesta de característica.El ejecutor kubernetes siempre clona en un directorio temporal.

Una estrategia de Git de none también reutiliza la copia local de trabajo, pero omite todas las operaciones de GitLab que normalmente realiza. Los scripts de clonación previa de GitLab Runner también se omiten, si están presentes. Esta estrategia podría significar que necesita agregar comandos fetch y checkout a su script .gitlab-ci.yml.

Se puede usar para trabajos que operan exclusivamente en artefactos, como un trabajo de implementación.Los datos del repositorio Git pueden estar presentes, pero es probable que estén desactualizados. Solo debe utilizar los archivos introducidos en la copia de trabajo local desde la caché o los artefactos.

Estrategia de submódulos de Git

Requiere GitLab Runner v1.10+.

La variable GIT_SUBMODULE_STRATEGY se usa para controlar si / cómo se incluyen los módulos Gitsub al obtener el código antes de una compilación. Puede configurarlos de forma global o por trabajo en la sección variables.

Hay tres valores posibles: nonenormal y recursive:

• none significa que submódulos no se incluye al buscar el codigo proyecto. Este es el valor predeterminado, que coincide con el comportamiento anterior a la versión 1.10.

• normal significa que solo se incluyen los submódulos de nivel superior. Es’sequivalent a:

  git submodule syncgit submodule update --init

• recursive significa que todos los submódulos (incluidos los submódulos de submódulos)están incluidos. Esta función necesita Git v1. 8.1 y versiones posteriores. Cuando utilice aGitLab Runner con un ejecutor que no esté basado en Docker, asegúrese de que la versión de Git cumple con ese requisito. Es equivalente a:

  git submodule sync --recursivegit submodule update --init --recursive

  Para que esta característica funcione correctamente, los submódulos deben estar configurados(en.gitmodules) con:

  • la URL HTTP(S) de un repositorio de acceso público, o
  • una ruta relativa a otro repositorio en el mismo servidor GitLab. Consulte la documentación de submódulos de Git.

  Git checkout

  Introducido en GitLab Runner 9.3.

  El GIT_CHECKOUT variable puede ser utilizada cuando el GIT_STRATEGY está ajustado aclone o fetch para especificar si un git checkout debe ejecutar. Si no se especifica, el valor predeterminado es true. Puede configurarlos globalmente o por trabajo en la secciónvariables.

  Si se establece en false , el runner:

  • al hacer fetch – actualiza el repositorio y deja la copia de trabajo en la revisión actual,
  • al hacer clone – clona el repositorio y deja la copia de trabajo en la rama default.

  Si GIT_CHECKOUT a true tanto clone y fetch funcionan de la misma manera.El corredor comprueba la copia de trabajo de una revisión relacionada con la canalización de IC:

  variables: GIT_STRATEGY: clone GIT_CHECKOUT: "false"script: - git checkout -B master origin/master - git merge $CI_COMMIT_SHA

  Git clean flags

  Introducido en GitLab Corredor 11.10

  El GIT_CLEAN_FLAGS variable se utiliza para controlar el comportamiento predeterminado degit clean después de comprobar las fuentes. Puede configurarlo globalmente o por trabajo en la secciónvariables.

  GIT_CLEAN_FLAGS acepta todas las opciones posibles de la etiqueta git cleancomando.

  git clean está deshabilitada si GIT_CHECKOUT: "false" se especifica.

  Si GIT_CLEAN_FLAGS es:

  • No se especifica, git clean banderas defecto -ffdx.
  • Dado el valor de nonegit clean no se ejecuta.

  Por ejemplo:

  variables: GIT_CLEAN_FLAGS: -ffdx -e cache/script: - ls -al cache/

  Git fetch extra flags

  Introducido en GitLab Corredor 13.1.

  El GIT_FETCH_EXTRA_FLAGS variable se utiliza para controlar el comportamiento degit fetch. Puede configurarlo globalmente o por trabajo en la sección variables.

  GIT_FETCH_EXTRA_FLAGS acepta todas las opciones de la etiqueta git fetch comando. Sin embargo, los indicadores GIT_FETCH_EXTRA_FLAGS se añaden después de los indicadores predeterminados que no se pueden modificar.

  Los indicadores predeterminados son:

  • GIT_DEPTH.
  • La lista de refspecs.
  • Un control remoto llamado origin.

  Si GIT_FETCH_EXTRA_FLAGS es:

  • No se especifica, git fetch banderas defecto --prune --quiet junto con los indicadores predeterminados.
  • Dado el valor de nonegit fetch se ejecuta sólo con los indicadores predeterminados.

  Por ejemplo, los indicadores predeterminados son --prune --quiet, por lo que puede hacer que git fetch sea más detallado anulando esto con solo --prune:

  variables: GIT_FETCH_EXTRA_FLAGS: --prunescript: - ls -al cache/

  La configuración anterior hace que git fetch se llame de esta manera:

  git fetch origin $REFSPECS --depth 50 --prune

  Donde $REFSPECS es un valor aportado al corredor internamente por GitLab.

  Clonación superficial

  Introducida en GitLab 8.9 como una característica experimental.

  Puede especificar la profundidad de obtención y clonación utilizando GIT_DEPTHGIT_DEPTH hace un clon superficial del repositorio y puede acelerar significativamente cloning.It puede ser útil para repositorios con un gran número de confirmaciones o binarios viejos y grandes. El valor se pasa a git fetch y git clone.

  En GitLab 12.0 y versiones posteriores, los proyectos recién creados tienen automáticamente un valor predeterminado git depth de 50.

  Si utiliza una profundidad de 1 y tiene una cola de trabajos o retryjobs, los trabajos pueden fallar.

  La obtención y clonación de Git se basa en una referencia, como un nombre de rama, por lo que los ejecutantes no pueden clonar un SHA de confirmación específico. Si hay varios trabajos en la cola, o está volviendo a intentar un trabajo antiguo, el commit que se va a probar debe estar dentro del historial de GIT que se clona. Establecer un valor demasiado pequeño para GIT_DEPTH puede hacer que sea imposible ejecutar estas confirmaciones antiguas y unresolved reference se muestra en los registros de tareas. A continuación, debe reconsiderar cambiar GIT_DEPTH a un valor más alto.

  Los trabajos que se basan en git describe pueden no funcionar correctamente cuando GIT_DEPTH está establecido, ya que solo parte del historial de Git está presente.

  Para obtener o clonar solo las últimas 3 confirmaciones:

  variables: GIT_DEPTH: "3"

  se puede establecer de forma global o por trabajo en el variables sección.

  Directorios de compilación personalizados

  Introducidos en GitLab Runner 11.10.

  De forma predeterminada, GitLab Runner clona el repositorio en una subtrama única del directorio$CI_BUILDS_DIR. Sin embargo, su proyecto puede requerir el código en un directorio específico (proyectos Go, por ejemplo). En ese caso, puede especificar la variable GIT_CLONE_PATH para indicar al corredor el directorio en el que clonar el repositorio:

  variables: GIT_CLONE_PATH: $CI_BUILDS_DIR/project-nametest: script: - pwd

  El GIT_CLONE_PATH ha de ser siempre dentro de $CI_BUILDS_DIR. El conjunto de directorios en $CI_BUILDS_DIR depende del ejecutor y la configuración de los corredores.builds_dirsetting.

  Esto solo se puede usar cuando custom_build_dir está habilitado en la configuración del runner.Esta es la configuración predeterminada para el docker y kubernetes ejecutores.

  Manejar la concurrencia

  Un ejecutor que usa una concurrencia mayor que 1 puede provocar errores. Es posible que varios trabajos funcionen en el mismo directorio si builds_dirse comparte entre trabajos.

  El corredor no intenta evitar esta situación. Corresponde al administrador y a los desarrolladores cumplir con los requisitos de configuración de runner.

  Para evitar este escenario, puede usar una ruta de acceso única dentro de $CI_BUILDS_DIR, ya que runnerexpone dos variables adicionales que proporcionan un único ID de concurrencia:

  • $CI_CONCURRENT_ID: ID único para todos los trabajos que se ejecutan dentro de albacea.
  • $CI_CONCURRENT_PROJECT_ID: ID único para todos los trabajos que se ejecutan dentro del ejecutor y el proyecto dados.

  La configuración más estable que debería funcionar bien en cualquier escenario y en cualquier ejecutor es usar $CI_CONCURRENT_IDen el GIT_CLONE_PATH. Por ejemplo:

  variables: GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/project-nametest: script: - pwd

  El $CI_CONCURRENT_PROJECT_ID debe ser utilizado en conjunción con la etiqueta $CI_PROJECT_PATHcomo $CI_PROJECT_PATH proporciona una ruta de acceso a un repositorio. Es decir, group/subgroup/project. Por ejemplo:

  variables: GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/$CI_PROJECT_PATHtest: script: - pwd

  Anidados rutas

  El valor de GIT_CLONE_PATH se expande una vez y anidación variableswithin no es compatible.

  Por ejemplo, define las dos variables a continuación en su archivo.gitlab-ci.yml :

  variables: GOPATH: $CI_BUILDS_DIR/go GIT_CLONE_PATH: $GOPATH/src/namespace/project

  El valor de GIT_CLONE_PATH se expande una vez dentro de$CI_BUILDS_DIR/go/src/namespace/project, y los resultados en failurebecause $CI_BUILDS_DIR no se ha expandido.

  Intentos de etapas de trabajo

  Introducido en GitLab, requiere GitLab Runner v1. 9+.

  Puede establecer el número de intentos que el trabajo en ejecución intenta ejecutar las siguientes etapas:

  Variable	Descripción
  ARTIFACT_DOWNLOAD_ATTEMPTS	Número de intentos de descarga de los artefactos de ejecutar un trabajo
  EXECUTOR_JOB_SECTION_ATTEMPTS	En GitLab 12.10 y más tarde, el número de intentos para ejecutar una sección de un puesto de trabajo después de un No Such Container error (ventana acoplable ejecutor solamente).
  GET_SOURCES_ATTEMPTS	Número de intentos para recuperar las fuentes de ejecutar un trabajo
  RESTORE_CACHE_ATTEMPTS	Número de intentos de restablecer la caché de ejecutar un trabajo

  El valor predeterminado es de un solo intento.

  Ejemplo:

  variables: GET_SOURCES_ATTEMPTS: 3

  Usted puede establecer de forma global o por trabajo en el variables sección.

  Las llamadas al sistema no están disponibles en GitLab.com corredores compartidos

  GitLab.com corredores compartidos corren en CoreOS. Esto significa que no puede usar algunas llamadas al sistema, como getlogin, desde la biblioteca estándar de C.

  Configuración de artefactos y caché

  Introducida en GitLab Runner 13.9.

  La configuración de artefactos y caché controla la relación de compresión de artefactos y cachés.Utilice esta configuración para especificar el tamaño del archivo producido por un trabajo.

  • En una red lenta, las cargas pueden ser más rápidas para archivos más pequeños.
  • En una red rápida donde el ancho de banda y el almacenamiento no son una preocupación, las cargas pueden ser más rápidas utilizando la relación de compresión más rápida, a pesar de que el archivo producido es más grande.

  Para que las páginas de GitLab sirvan solicitudes de rango de HTTP, los artefactos deben usar la configuración ARTIFACT_COMPRESSION_LEVEL: fastest, ya que solo los archivos zip sin comprimir admiten esta función.

  También se puede habilitar un medidor para proporcionar la velocidad de transferencia para cargas y descargas.

  variables: # output upload and download progress every 2 seconds TRANSFER_METER_FREQUENCY: "2s" # Use fast compression for artifacts, resulting in larger archives ARTIFACT_COMPRESSION_LEVEL: "fast" # Use no compression for caches CACHE_COMPRESSION_LEVEL: "fastest"

  Variable	Descripción
  TRANSFER_METER_FREQUENCY	Especificar la frecuencia con la impresión del medidor de velocidad de transferencia. Se puede establecer una duración (por ejemplo, 1s o 1m30s). Una duración de 0 deshabilita el medidor (predeterminado). Cuando se establece un valor, la canalización muestra un medidor de progreso para cargas y descargas de artefactos y caché.
  ARTIFACT_COMPRESSION_LEVEL	Para ajustar la relación de compresión, a fastestfastdefaultslow, o slowest. Esta configuración solo funciona con el archivador Fastzip, por lo que el indicador de características de GitLab Runner FF_USE_FASTZIP también debe estar habilitado.
  CACHE_COMPRESSION_LEVEL	To adjust compression ratio, set to fastestfastdefaultslow, or slowest. This setting works with the Fastzip archiver only, so the GitLab Runner feature flag FF_USE_FASTZIP must also be enabled.