Jenkins et les emplois multi-configurations (matrices)

Question

Pourquoi y a-t-il deux types de travaux pour Jenkins, à la fois le projet multi-configuration et le projet libre ? J'ai lu quelque part qu'une fois que vous avez choisi l'un d'entre eux, vous ne pouvez pas vous convertir à l'autre (facilement). Pourquoi ne choisirais-je pas toujours le projet multi-configuration afin d'être sûr des changements futurs ?

Je voudrais mettre en place un build pour un projet qui se construit à la fois sur Windows et Unix (et d'autres plateformes également). J'ai trouvé cette question ), qui pose la même question, mais je ne comprends pas vraiment la réponse. Pourquoi aurais-je besoin de trois projets matriciels (et non de trois projets de style libre), un pour chaque plateforme ? Pourquoi ne puis-je pas les garder tous dans une seule matrice, avec les plates-formes ET (par exemple) la version de gcc sur un axe et (mes) versions de logiciels sur l'autre ?

J'ai aussi lu cet article de blog mais qui construit tout sur la même machine, avec juste des versions différentes de Python.

Donc, en résumé : comment la plupart des gens configurent-ils un projet multi-configuration visant de nombreuses plateformes différentes ?

Answer 1

Les deux types d'emplois ont des fonctions distinctes :

• Les travaux libres : ils vous permettent de construire votre projet sur un seul ordinateur ou une étiquette (groupe d'ordinateurs, par exemple "Windows-XP-32").
• Travaux multi-configuration : ils vous permettent de construire votre projet sur plusieurs ordinateurs ou étiquettes, ou un mélange des deux, par exemple Windows-XP, Windows-Vista, Windows-7 et RedHat -. utile pour vérifier la compatibilité ou la construction pour des plateformes multiples (programmes qt ?)

Si vous avez un projet que vous voulez construire sur Windows et Unix, vous avez deux options :

• créer une tâche libre distincte pour chaque configuration, auquel cas vous devez gérer chacune d'elles individuellement
• Vous avez un travail de multi-configuration, et vous sélectionnez 2 (ou plus) étiquettes/ordinateurs/esclaves - 1 pour Windows et 1 pour Unix. Dans ce cas, vous ne devez gérer qu'un seul job pour la construction.

Vous pouvez garder les versions de gcc sur un axe, et les versions du logiciel sur un autre. Il n'y a aucune raison pour que vous ne puissiez pas le faire.

La question que vous mettez en lien est pertinente, mais elle n'est pas directement liée à votre question : dans son cas, il s'agissait d'un emploi à configuration multiple. A qui, en cas de succès, déclenche un autre travail. B . Or, dans un travail multi-configuration, si l'une des configurations échoue, le travail entier échoue (évidemment, puisque vous voulez que votre projet soit construit avec succès sur toutes vos configurations).

À mon avis, pour construire le même projet sur plusieurs plates-formes, la meilleure façon de procéder est d'utiliser un travail de type multi-configuration.

Answer 2

Une autre option consiste à utiliser une étape de construction python pour vérifier le système d'exploitation actuel et ensuite appeler un script d'installation ou de construction approprié. Dans le script python, vous pouvez sauvegarder l'environnement mis à jour dans un fichier et réinjecter l'environnement en utilisant le plugin EnvInject pour les étapes de construction suivantes. En fonction de la taille de votre environnement de construction, vous pouvez également utiliser un outil de construction multiplateforme comme SCons.

Answer 3

Vous pourriez créer un script (par ex. construire ) et un fichier de traitement par lots (p. ex. build.bat ) qui sont enregistrés dans votre code source. Dans Jenkins, lors de votre étape de construction, vous pouvez appeler $WORKSPACE/build - Windows exécutera build.bat alors que Linux exécutera construire .

Answer 4

Vous pourriez utiliser la variable que jenkins crée lorsque vous définissez un axe de matrice de configuration. Par exemple : Vous créez un axe esclave avec le nom OSTYPE et vérifiez les deux esclaves (Windows et Linux). Ensuite, vous créez deux étapes de construction séparées et vérifiez la variable d'environnement OSTYPE.

Vous pourriez utiliser un langage script amélioré à la place, comme python, qui est multi-plateforme et peut réaliser la même fonctionnalité indépendamment du nom des esclaves et en une seule étape de construction.

Answer 5

Si vous suivez la voie de la matrice avec Windows et autre chose, vous aurez besoin du plugin XShell. Il vous suffit de créer vos deux scripts de construction tels que "build.bat" pour cmd et "build" pour bash, et de dire à XShell d'exécuter "build". Le bon sera exécuté dans chaque cas.