warnings ng plugin devenv
1.0.0
Cet environnement de développement basé sur Docker est destiné aux nouveaux contributeurs des avertissements Jenkins et des plugins de couverture pour réduire le temps de montée en puissance initial. Il se compose des parties suivantes:
J'ai présenté cet environnement de développement lors d'une rencontre en ligne Jenkins enregistrée en janvier 2022.
L'environnement de développement a été testé sur MacOS, Ubuntu Linux (dans une machine virtuelle exécutée sur MacOS) et Windows. Les demandes de traction sont toujours les bienvenues.
Dernière version des outils suivants:
De plus, les dernières versions des outils suivantes sont nécessaires:
Si des erreurs se produisent, notez les indices de dépannage ci-dessous. Pour les utilisateurs de Windows: utilisez le Git Bash pour exécuter les scripts shell.
./bin/clone-repos-https.sh (ou ./bin/clone-repos.sh si vous avez déjà configuré une clé SSH dans github). Vous devez attendre que la construction réussit avant d'ouvrir Intellij, sinon Intellij ne trouvera pas toutes les classes générées. La première fois que les utilisateurs de Maven doivent attendre quelques minutes jusqu'à ce que toutes les dépendances aient été téléchargées depuis Maven Central.warnings-ng-plugin-devenv./bin/jenkins.sh . Cette commande construit l'image Jenkins Docker, télécharge tous les plugins enregistrés et initialise l'espace de travail Jenkins avec certains travaux. Cela nécessite également quelques minutes (voir l'étape 9). Si tous les téléchargements ont réussi, mais l'installation a échoué en raison d'erreurs, les réparez et exécutez mvn -V -U -e install –DskipTests pour réessayer uniquement l'installation.
Si la ligne de commande d'erreur est trop longue. " se produit, exécutez les étapes suivantes:
@argfile (Java9+)Si les tests échouent en raison d'un délai d'expiration de test Jenkins, exécutez les étapes suivantes:
-Djenkins.test.timeout=1000 . Cela augmente la limite de délai d'expiration à 1000 secondes. Vous pouvez utiliser un script de shell simple ( ./bin/clone-repos.sh ) pour clone et construire les modules en une seule étape. Le script vérifie les modules suivants à l'aide du protocole GIT SSH. Cela nécessite que vous ayez enregistré votre clé publique dans GitHub. Si vous n'avez pas de touches dans GitHub, vous pouvez également utiliser le script ./bin/clone-repos-https.sh qui utilise le protocole HTTPS.
Lorsque vous prévoyez de fournir une demande de traction pour l'un des plugins, vous devez créer une fourche du référentiel et apporter toutes les modifications dans cette fourche. J'ai créé une documentation de collaboration GitHub dans mon projet de style de codage.
Intellij (Ultimate) est le principal environnement de développement pris en charge pour le plugin d'avertissement. Un projet prédéfini est stocké dans le dossier .idea qui fait référence à tous les modules du plugin d'avertissement. Ce projet contient des préréglages de mon style de codage et d'autres configurations utiles.
Il devrait également être possible d'utiliser d'autres IDE (Eclipse, NetBeans, Visual Studio Code).
Utilisez les configurations d'exécution IntelliJ fournies All in [module-name] pour exécuter l'unité et les tests d'intégrations du module correspondant. Ces configurations sont déjà configurées pour enregistrer la couverture de la branche des packages de modules correspondants (utilisez l' Run with Coverage ).
Avant de pouvoir déboguer vos modifications, vous devez d'abord savoir où votre code est en cours d'exécution: sur le contrôleur ou sur l'agent? Si vous n'êtes pas sûr, exécutez les deux débogueurs distants, définissez certains points d'arrêt et attendez que le débogueur correspondant s'arrête.
La configuration Docker Compose démarre automatiquement le contrôleur Jenkins en mode «débogage», c'est-à-dire qu'il écoute les demandes de débogage distantes. Si votre code s'exécute dans le contrôleur, vous devez joindre un débogueur distant sur localhost:8000 (mappé au même port dans le conteneur Docker). Utilisez la configuration de débogage Jenkins Controller (Remote Debugger) fourni pour connecter un débogueur dans Intellij.
La configuration Docker Compose démarre également l'agent Jenkins automatiquement en mode «débogage», c'est-à-dire qu'il écoute les demandes de débogage distantes. Joignez un débogueur distant sur localhost:8001 (mappé au même port dans le conteneur Docker) pour déboguer le code exécuté sur l'agent. Utilisez la configuration de débogage Jenkins Agent (Remote Debugger) fourni pour connecter un débogueur dans Intellij.
Les tests d'interface utilisateur peuvent être démarrés à l'aide des UI Tests [module] (Firefox) ou UI Tests [module] (Chrome) . Notez que les deux lanceurs nécessitent une installation des pilotes de sélénium correspondants. Si ces pilotes ne sont pas installés dans /opt/bin sur votre machine locale, vous devez adapter les configurations de lanceur pour correspondre à votre configuration.
Tous les tests d'interface utilisateur nécessitent l'exécution dans un sujet donné testé (c'est-à-dire Jenkins testé, JUT), voir le projet de harnais de test d'acceptation pour plus de détails.
Cet environnement de développement contient une installation Jenkins personnalisée où vous pouvez déployer vos plugins modifiés, afin que vous puissiez voir vos modifications directement dans certains travaux préconfigurés qui utilisent ces plugins.
Démarrez le contrôleur Jenkins fourni dans ce projet (vous devez installer Docker et Docker-Compose). Ouvrez un terminal et exécutez ./jenkins.sh dans le dossier de niveau supérieur. Cette commande est un wrapper pour docker-compose up : il utilise les bons paramètres d'utilisateur et de groupe afin que les autorisations du volume Docker pour le dossier Home Jenkins soient correctement définies. Cette commande crée un conteneur Docker pour le contrôleur Jenkins et un pour l'agent Java. Cela nécessitera un certain temps lorsque l'on appelle la première fois, car les images Docker seront composées. Une fois les images créées, les deux conteneurs suivants seront démarrés:
Vous pouvez ensuite ouvrir Jenkins à l'URL http: // localhost: 8080 /. Utilisez les informations d'identification suivantes pour vous connecter en tant qu'administrateur:
Le répertoire domestique du contrôleur Jenkins (Jenkins_Home) est monté comme un volume Docker. C'est-à-dire qu'il est visible sur l'hôte en tant que répertoire normal sur ./docker/volumes/jenkins-controller . Il survivra aux séances et peut être modifié directement sur l'hôte, voir la documentation officielle pour plus de détails. Cela aide à inspecter les fichiers qui ont été créés par le contrôleur Jenkins.
En raison d'un problème de performance dans le plugin DSL de Jenkins, la configuration de l'instance New Jenkins est très lente. Par conséquent, il est logique de supprimer la partie de configuration du travail de votre fichier jenkins.yaml après la création des travaux. Vous pouvez écraser le contenu du fichier ./docker/volumes/jenkins-home/jenkins.yaml dans votre instance Jenkins nouvellement créée avec le contenu de jenkins-no-jobs.yaml .
Les volumes sous macOS sont assez lents. Sur mon MacBook exécutant le travail Jenkins fourni du analysis-model dans le conteneur Docker est plus lent que d'exécuter le même travail Jenkins dans un conteneur Docker qui s'exécute dans une machine virtuelle Linux sur le même MacBook (sonne en quelque sorte absurde?).
Une fois que vous avez terminé vos modifications de développement locales (c'est-à-dire les tests unitaires sont tous verts), vous devez tester vos modifications dans Jenkins. Cela aide également à préparer un test d'intégration ou un test d'interface utilisateur pour votre modification.
Si vous n'avez que des modifications dans le module analysis-model (et que vous n'avez ajouté aucune nouvelle méthode API), vous devez reconstruire et installer le module Maven analysis-model.jar et ensuite reconstruire le analysis-model-api-plugin Jenkins en wrapper Jenkins associé. Ce plugin doit ensuite être déployé sur Jenkins.
Ce processus est simplifié en exécutant le script ./bin/go.sh Dans le module analysis-model , il installera le module analysis-model.jar dans votre référentiel Maven local. Ensuite, ce script créera le plugin réel et le déploiera dans Jenkins.
Si vous n'avez que des changements dans le plugin d'avertissement-ng, vous devez reconstruire le plugin Jenkins warnings-ng.jpi et le déployer sur Jenkins. Vous pouvez utiliser l'un des scripts de shell suivants pour cette tâche:
./bin/clean.sh : construit le plugin à l'aide de mvn clean install et le déploie sur le succès dans l'instance Jenkins../bin/go.sh : construit le plugin à l'aide de mvn clean install -DskipITs (saute les tests d'intégration) et le déploie sur le succès dans l'instace Jenkins../bin/skip.sh : construit le plugin à l'aide de mvn clean install -DskipTests (saute tous les tests et analyse statique) et le déploie sur le succès dans l'instance Jenkins.FAIRE
Si vous avez des modifications dans l'un des plugins de la présiction (API ou implémentation GIT), vous devez reconstruire ces plugins Jenkins et les déployer dans l'instance Jenkins.
Pour simplifier ce processus, exécutez le script ./go.sh dans le dossier du plugin correspondant, il construire le plugin et le déployer sur le succès à Jenkins.
Avant d'apporter des changements de rupture, veuillez me contacter. En règle générale, il est possible d'apporter des modifications en arrière compatibles.
Les scripts de construction de la dernière section peuvent également être démarrés à l'aide de l'un des lanceurs Intellij Build and Deploy [module-name] . Ces lanceurs construisent le plugin correspondant et le déploient en Jenkins.
Les tests d'interface utilisateur peuvent être démarrés à l'aide d'une configuration de lanceur Intellij ou à l'aide d'un script de ligne de commande. Comme déjà mentionné, tous les tests d'interface utilisateur nécessitent de s'exécuter dans un sujet donné testé. Dans notre cas, nous utilisons la dernière version Jenkins LTS disponible et l'ensemble prédéfini de plugins de notre image Docker.
Les tests d'interface utilisateur peuvent être démarrés à l'aide des UI Tests Warnings (Firefox) ou UI Warnings Tests (Chrome) . Notez que les deux lanceurs nécessitent une installation des pilotes de sélénium correspondants. Si ces pilotes ne sont pas installés dans /opt/bin sur votre machine locale, vous devez adapter les configurations de lanceur pour correspondre à votre configuration.
Vous pouvez également démarrer les tests d'interface utilisateur à l'aide des scripts de shell fournis testFirefox.sh ou testChrome.sh . Notez que vous devrez peut-être également adapter ces scripts (voir la section précédente).
