Nous possédons une organisation Github avec des centaines de référentiels créés par des contributeurs. Nous aimerions configurer un serveur Jenkins qui effectue certaines tâches standard pour chaque commit dans l'un des dépôts de notre organisation Github. Le flux CI prévu est assez simple:
myorg/foobar myorg appelle le serveur Jenkins myorg/foobar Je suis nouveau sur Jenkins et je suis complètement perdu sur les plugins ou le type de travail dont j'ai besoin pour configurer cela.
J'ai essayé de créer une "organisation GitHub" Jenkins pour mon organisation Github, mais cela me dit simplement "Ce dossier est vide, il n'y a aucun dépôt trouvé contenant des projets à construire" . Je ne sais pas non plus où le webhook de l'organisation github doit être configuré.
Nous ne voulons pas configurer des jobs / jenkinsfiles / webhook séparés pour tous les dépôts, mais simplement utiliser un script standard qui est exécuté pour chaque commit dans chaque dépôt, et le déclencher via un seul webhook d'organisation gh. Est-ce possible?
5 Réponses :
Vous avez plus d'une exigence ici. Passons en revue un par un.
a) Organisation Jenkins GitHub: Cela analysera toute votre organisation GitHub et créera autant de jobs que nécessaire pour construire vos référentiels car avoir un seul job sur Jenkins n'est pas la norme. En gros, vous avez perdu des données d'historique (Jenkins n'a aucune idée qu'il construit des éléments différents à chaque itération). Il dit dans l'aide "Analyse une organisation GitHub (ou un compte utilisateur) pour tous les référentiels correspondant à certains marqueurs définis.".
b) Essayez de voir Jenkins comme un automate, pas quelque chose qui hébergera toute la logique de construction / déploiement. Ce que je fais, c'est créer des fichiers comme "build.sh", "deploy.sh", etc. De cette façon, je peux construire et déployer directement à partir de mon shell. Donc seulement après cela, je crée des scripts pour Jenkins, qui appellent simplement des scripts de construction / déploiement, peu importe ce qu'ils font réellement. Jenkins n'a pas besoin de savoir. Un effet secondaire est que tous vos projets «peuvent être construits de la même manière», qu'ils soient NodeJS, Python ou autre. Bien sûr, vous pourriez avoir besoin de dépendances supplémentaires dans certains cas, et Docker peut vraiment vous aider ici.
c) J'ai fait quelque chose de similaire dans le passé, ayant moins de tâches que les dépôts / branches / pull-requests. Jenkins est une sorte de vidage, et quelques plugins peuvent aider ici. Mais dans votre cas, si vous voulez vraiment avoir un travail, vous n'avez besoin que d'un travail paramétré régulier. L'astuce est que votre webhook global de l'organisation Github ne pointera pas vers Jenkins. Il doit pointer vers un autre endroit, un code que vous maintenez. Ce code peut analyser la charge utile de Github, l'analyser, peut éventuellement rappeler GitHub ("y a-t-il une pull request pour cette branche? Non? Alors oubliez-la") pour améliorer son arbre de décision, et à la fin, déclencher cette tâche unique sur Jenkins avec tous les paramètres que vous avez pu capturer. De tels paramètres indiqueront à la tâche unique le dépôt à cloner, l'environnement sur lequel déployer et c'est tout. Vous connaissez déjà les noms de scripts, car ils sont standard.
d) Cela dit, je demanderais ... avez-vous besoin d'un Jenkins? Ce parser-little-software peut-il réellement cloner votre dépôt et exécuter quelques scripts dans un conteneur Docker? Un builder-docker-container qui a toutes les dépendances à l'intérieur?
e) À propos de "répondre" à GitHub, je l'ai fait en utilisant Python. Il existe des bibliothèques GitHub, j'ai donc pu récupérer des éléments de Jenkins et publier des messages API pour alimenter GitHub avec les statuts de construction. Puisque j'utilisais en fait une instance Jenkins, mon outil était un courtier d'intermédiaire. Dans votre cas, pour un seul travail, un conteneur Docker jouera bien le rôle.
Espère que cela aide avec une perspective différente.
Si vous souhaitez réellement utiliser une instance Jenkins, la plupart de ce que j'ai dit ici peut toujours être utilisé.
Pouvez-vous préciser si (a) est possible icw / a freestyle job config (c'est-à-dire exécuter un script fixe sans valider un Jenkinsfile dans chaque dépôt git)? J'ai réussi à définir un travail freestyle pour un seul dépôt, ou à scanner myorg pour tous les dépôts, mais je ne sais pas comment appliquer ce travail à tous les dépôts scannés.
Si vous recherchez des dépôts, quelque chose doit être là, comme les fichiers Jenkinsfile. Sur un travail freestyle, vous n'avez pas nécessairement besoin de configurer un référentiel. C'est juste un travail, qui ne peut qu'imprimer un bonjour le monde et ensuite sortir. Ensuite, vous pouvez appeler quelques scripts pour effectuer réellement le clonage, la construction, etc. (approche mono-tâche). J'avais un référentiel appelé "jenkins-scripts", qui consistait simplement à cloner son contenu sur Jenkins. Puis comme je n'avais qu'un nœud maître Jenkins, tous mes jobs (j'en avais beaucoup) faisaient référence à quelque chose comme "$ WORKSPACE /../../ scripts-jenkins / build.sh", par exemple.
Mais gardez à l'esprit que GitHub parle des événements et que Jenkins a besoin d'instructions spécifiques pour faire ce dont vous avez besoin. C'est pourquoi il existe des plugins Jenkins pour interagir avec GitHub. Ce que j'ai décrit sur c) est un WebService qui reçoit la charge utile et appelle Jenkins sur ce travail de style libre particulier, avec des paramètres spécifiques.
Je ne suis pas sûr dans quelle mesure cette réponse vous aidera , mais je serai heureux même si elle donne un aperçu des pipelines Jenkins.
J'élabore la procédure à suivre en utilisant les pipelines Jenkins , sinon à un moment donné, vous devez déplacer votre build et déployer vers des pipelines pour Infrastructure en tant que code .
À partir des plugins Jenkins , voici les plugins obligatoires pour la procédure que je vais expliquer ici:
Configuration Jenkins
organisation Github à partir des options ci-dessous: 
Owner doit être votre organisation où des centaines de dépôts sont disponibles. 
également, configurez quel fichier et quelles branches pour rechercher dans un dépôt pour déclencher une compilation. chemin du script est le fichier qui effectue les étapes (probablement de construction et de déploiement) pour les dépôts. Ainsi, tous les dépôts ne seront détectés ou affichés dans Jenkins que si un fichier portant ce nom est disponible dans les dépôts.
Jenkins analyse l ' organisation configurée selon l'intervalle mentionné ici. Il détecte tous les ajouts / suppressions de dépôts et commits également . Bon pour configurer le nombre de builds à stocker, si nécessaire.
Configuration du référentiel / organisation Git
Configurer les webhooks dans github
Configurez les événements qui nécessitent des notifications à Jenkins .
Protection des succursales et vérifications du statut des PR
Protéger la branche en activant les vérifications appropriées aidera à restreindre les validations de quelques groupes de personnes une fois les vérifications d'état réussies . Cela permet de maintenir une bonne qualité de code.
Voici l'instantané qui montre le statut des vérifications d'état lorsqu'un PR est soulevé . Sur la base de cela, les évaluateurs pourront décider d'approuver le PR.
Ce lien explique en détail la procédure que j'ai décrite ici.
Est-il possible de configurer ce projet avec une organisation github ayant déjà plus de 300 référentiels. En interne, le scanner jenkins ne scanne que les 28 premiers dépôts git selon la pagination
En supposant que vos Jenkins fonctionnent sous Linux ou MacOS, ou dans Windows prenant en charge les commandes Shell Script, configurez un travail Jenkins pour exécuter le script ci-dessous. N'oubliez pas de remplacer les champs utilisateur et mot de passe et de lire les lignes de commentaire afin de le comprendre et peut-être l'améliorer.
curl -i -u "user":"password" "https://github.com/your_organization" | grep "codeRepository" | awk -F '"' '{print $8}' | while read line; do
mkdir "_temp_repo"
cd "_temp_repo"
# `--depth=1` clones the last commit only improving the speed of the clone
# if you want to clone a specific branch add `-b branch` to the command below
git clone --depth=1 "https://github.com"$line .
# execute here your peding commands...
git add .
git commit -am "[pending] XPTO..."
git push
# execute here your success/failure commands...
git add .
git commit -am "[success/failure] XPTO..."
git push
cd ..
rm -rfv "_temp_repo"
done
Je suggérerais de créer un fichier SH et de l'exécuter en mode verbeux: sh -x ./my_script.sh.
Afin de l'exécuter à chaque nouvelle mise à jour, configurez un webhook Github pour cette tâche.
L'approche standard serait de créer un nouveau pipeline multibranch qui analyse votre organisation à la recherche de nouveaux référentiels. Chaque dépôt doit avoir un jenkinsfile avec les instructions de construction. Mais en général, il est également possible de réaliser ce que vous essayez de manière programmatique.
Quelle serait mon approche:
J'utiliserais le Folders Plugin pour créer un dossier pour ce type de tâches.
/ p>
Si c'est vraiment ce que vous essayez de faire, je pourrais développer davantage.
Répondre à ma propre question:
Comme plusieurs personnes l'ont souligné, Jenkins assume un travail par référentiel. Le plugin Github Organization n'a pas bien fonctionné car il est maladroit et vous oblige à valider et à maintenir un Jenkinsfile dans chacun de vos dépôts, ce que je voulais précisément éviter.
L'information critique que je ne connais pas est que Jenkins a une excellente CLI et une API REST pour contrôler les tâches, et une configuration de tâche unique peut facilement être exportée sous forme de simple fichier xml.
Donc, ce que j'ai fait, c'est configurer un travail Jenkins pour l'un des dépôts via l'interface graphique Jenkins. Ensuite, j'ai écrit un simple client REST qui télécharge le config.xml pour ces travaux, et crée ou met à jour les travaux Jenkins pour chacun des référentiels de notre organisation Github.
Les builds sont automatiquement déclenchés par le webhook Github (à l'échelle de l'organisation) si l'URL correspond à celle de l'un des référentiels. Aucun plugin d'organisation Github spécial n'est nécessaire.