online hudson jenkins

hudson - jenkins online



¿Cómo evitar que ciertos trabajos de Jenkins se ejecuten simultáneamente? (6)

Tengo un par de trabajos que usan un recurso compartido (base de datos), que a veces puede hacer que las compilaciones fallen en el (raro) evento de que los trabajos se activen simultáneamente.

Dados los trabajos A a E, por ejemplo, ¿hay alguna manera de especificar que A y C nunca se deberían ejecutar simultáneamente ?

Además del recurso mencionado anteriormente, las construcciones son independientes entre sí (no, por ejemplo, en una relación aguas arriba / aguas abajo).

Una forma de "fuerza bruta" limitaría el número de ejecutores a uno, pero obviamente eso es menos que ideal si la mayoría de los trabajos se pueden ejecutar simultáneamente y no faltan recursos informáticos en el servidor de compilación.

Actualmente hay 2 formas de hacer esto:

  • Utilice el complemento Throttle Concurrent Builds .
  • Configure esos trabajos para que se ejecuten en un esclavo que tenga solo 1 ejecutor.

Eche un vistazo al plugin de Jenkins External Dispatcher Dispatcher , que se publicó por primera vez en noviembre de 2012. Este plugin (relativamente) nuevo parece cubrir exactamente este caso de uso.

Esa es una vieja pregunta, pero el tema aún puede ser relevante, especialmente cuando se ejecutan pruebas de aplicaciones en Jenkins.

El complemento de recursos bloqueables le permite definir recursos bloqueables que las compilaciones pueden usar. Si su construcción requiere un recurso, se necesita el bloqueo. Si una segunda construcción requiere el mismo recurso (que luego ya está bloqueado), se pondrá en cola para que el recurso sea libre.

Aunque los documentos usan computadoras o impresoras como ejemplos de recursos bloqueables, el ejemplo de la base de datos de arriba debería funcionar también.

En oposición al complemento Locks and Latches mencionado en las respuestas de 2012, este paquete parece mantenerse actualmente (actualmente ~ 2016).

Nota: no necesita hardware físico o virtual para un esclavo / nodo, puede configurar "esclavos" que se ejecutan en el servidor maestro.

Administrar Jenkins> Administrar nodos> Nuevo nodo

y hacer un "esclavo tonto" cada uno con su propio directorio raíz.

Cree algunos esclavos, ejecútelos cuando se inicie el servidor, y luego esencialmente ha creado grupos de ejecutores.

Podrías tener, por ejemplo ...

db: solo un ejecutor en tu caso. compilar - límite según hardware o # de CPU. Guiones: tienen muchos ejecutores para todos esos trabajos pequeños que Jenkins es bueno en hacer.

Una vieja pregunta, y si esto funcionará para su aplicación, no puedo estar seguro ya que no mencionó los detalles de su solicitud. Sin embargo, quería agregar la forma en que manejé esto en nuestro conjunto de pruebas de aplicaciones Rails.

La configuración de la base de datos de nuestra aplicación ( database.yml ) no está en el repositorio fuente. En cambio, vive en /var/lib/configs/uniquing_database.yml en la máquina virtual que ejecuta nuestra instancia de Jenkins.

Uno de los pasos de nuestro proceso de compilación consiste en copiar este archivo de configuración en el espacio de trabajo del proyecto:

cp /var/lib/jenkins/configs/myapp_unique_database.yml config/database.yml

y esa configuración toma en cuenta la información de espacio de trabajo y número de compilación expuesta al entorno por Jenkins para crear una base de datos con un nombre único para ese trabajo y su ejecución específica:

test: adapter: postgresql encoding: unicode host: 127.0.0.1 port: 5432 database: myapp_test<%= ENV[''JOB_NAME''].split(''/'').last %><%= ENV[''BUILD_NUMBER''] %>

El resto de nuestra compilación continúa sin ningún conocimiento o cuidado de que se ejecute en una base de datos distinta. Finalmente, al final de nuestra compilación, nos aseguramos de eliminar esa base de datos para que no tengamos un montón de bases de datos de prueba que contaminen el sistema de archivos:

RAILS_ENV=test bundle exec rake db:drop