Comment empêcher certains travaux Jenkins de fonctionner simultanément?

J’ai quelques tâches qui utilisent une ressource partagée (firebase database), ce qui peut parfois entraîner l’échec des builds dans l’événement (rare) où les jobs sont déclenchés simultanément.

Compte tenu des tâches A à E, par exemple, existe-t-il un moyen de spécifier que A et C ne doivent jamais être exécutés simultanément ?

Outre la ressource susmentionnée, les builds sont indépendants les uns des autres (pas par exemple dans une relation amont / aval).

Une méthode “brute-force” limiterait le nombre d’exécutants à un seul, mais cela n’est évidemment pas idéal si la plupart des travaux peuvent être exécutés simultanément et que les ressources informatiques du serveur de génération ne manquent pas.

    Il y a actuellement 2 façons de le faire:

    • Utilisez le plug-in Throttle Concurrent Builds .
    • Configurez les tâches à exécuter sur un esclave n’ayant qu’un seul exécuteur.

    Le plugin Locks and Latches ici devrait vous aider.

    Cette question est probablement une dupe de Comment puis-je m’assurer qu’un seul d’une certaine catégorie de travail fonctionne à la fois à Hudson?

    Jetez un coup d’oeil au plugin External Resource Dispatcher Jenkins, qui a été publié pour la première fois en novembre 2012. Ce nouveau plugin (relativement) semble couvrir exactement ce cas d’utilisation.

    C’est une vieille question, mais le sujet peut toujours être pertinent, en particulier lors de l’exécution de tests d’application sur Jenkins.

    Le plug- in de ressources verrouillables vous permet de définir des ressources verrouillables pouvant être utilisées par les builds. Si votre build nécessite une ressource, elle prend le verrou. Si une deuxième version nécessite la même ressource (qui est déjà verrouillée), elle sera mise en queue pour que la ressource soit libre.

    Bien que les documents utilisent des ordinateurs ou des imprimantes comme exemples de ressources verrouillables, l’exemple de la firebase database ci-dessus devrait également fonctionner.

    Contrairement au plug -in Locks and Latches mentionné dans les réponses de 2012, ce package semble être actuellement maintenu (actuellement ~ 2016).

    NB: vous n’avez pas besoin de matériel physique ou virtuel pour un esclave / nœud, vous pouvez configurer des “esclaves” qui fonctionnent sur le serveur maître.

    Gérer Jenkins> Gérer les nœuds> Nouveau nœud

    et faire un “esclave muet” chacun avec son propre répertoire racine.

    Créez quelques esclaves, exécutez-les au démarrage du serveur et vous avez essentiellement créé des pools d’exécuteurs.

    Vous pourriez avoir, disons …

    db – un seul exécuteur dans votre cas. comstack – limite selon le matériel ou le nombre de processeurs. scripts – ont beaucoup d’exécuteurs pour tous ces petits travaux que Jenkins est bon à faire.

    Ancienne question, et si cela fonctionnera pour votre application, je ne peux pas être sûr que vous n’avez pas mentionné les détails de votre application. Cependant, je voulais append la manière dont j’ai géré ceci dans notre suite de tests d’application Rails.

    La configuration de la firebase database de notre application ( database.yml ) n’est pas dans le référentiel source. Au lieu de cela, il se trouve dans /var/lib/configs/uniquing_database.yml sur la machine virtuelle qui exécute notre instance Jenkins.

    L’une des étapes de notre processus de génération consiste à copier ce fichier de configuration dans l’espace de travail du projet:

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

    et que config prend en compte les informations sur l’espace de travail et le numéro de compilation dans l’environnement de Jenkins afin de créer une firebase database unique pour ce travail et son exécution spécifique:

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

    Le rest de notre version se déroule sans aucune connaissance ni souci de son exécution dans une firebase database distincte. Enfin, à la fin de notre compilation, nous nous assurons de supprimer cette firebase database afin de ne pas avoir un tas de bases de données de test qui polluent le système de fichiers:

     RAILS_ENV=test bundle exec rake db:drop