\newpage ## Intégration continue Une fois Gitea et Drone installés et configurés, nous allons pouvoir rentrer dans le vif du sujet : faire de l'intégration continue sur notre premier projet ! ### Créez un dépôt pour `youp0m` Reprenez les travaux déjà réalisés : nous allons notamment avoir besoin du `Dockerfile` que nous avons réalisé pour ce projet `youp0m`. Après avoir créé (ou migré pour les plus malins !) le dépôt `youp0m`[^urlyoup0m] dans gitea, synchronisez les dépôts dans Drone, puis activez la surveillance de `youp0m`. [^urlyoup0m]: Nous allons devoir rédiger un fichier `drone.yml`, que l'on placera à la racine du dépôt. C'est ce fichier qui sera traité par DroneCI pour savoir comment compiler et tester le projet. ::::: {.warning} Un fichier `drone.yml` existe déjà à la racine du dépôt. Celui-ci pourra vous servir d'inspiration, mais il ne fonctionnera pas directement dans votre installation. **Vous rencontrerez des problèmes inattendus si vous utilisez le fichier `.drone.yml` du dépôt.** Vous **DEVEZ** partir d'un fichier vide et suivre la documentation pour obtenir un `.drone.yml` fonctionnel. ::::: ### Définir les étapes d'intégration Toutes les informations nécessaires à l'écriture du fichier `.drone.yml` se trouvent dans l'excellente documentation du projet :\ . Les étapes sont sensiblement les mêmes que dans le `Dockerfile` que nous avons écrit précédemment. Committons puis poussons notre travail. Dès qu'il sera reçu par Gitea, nous devrions voir l'interface de Drone lancer les étapes décrites dans le fichier. ![Drone en action](drone-run.png){height=6cm} ::::: {.warning} **IMPORTANT :** si vous avez l'impression que ça ne marche pas et que vous avez réutilisé le fichier présent sur le dépôt au lieu de partir de l'exemple donné dans la documentation, **commencez en partant de l'exemple de la documentation** ! Le fichier présent sur le dépôt **ne fonctionnera pas** dans votre situation ! ::::: Lorsqu'apparaît enfin la ligne `git.nemunai.re/youp0m`, le projet est compilé ! ### Inspection qualité Nous n'avons pas encore de test à proprement parler. Nous allons utiliser [Sonarqube](https://www.sonarqube.org/) pour faire une revue qualité du code ! Tout d'abord, il faut lancer le conteneur Sonarqube :
```bash docker run --rm -d --name sonarqube --network drone -p 9000:9000 sonarqube ```
Le service met un bon moment avant de démarrer, dès qu'il se sera initialisé, nous pourrons accéder à l'interface sur . En attendant qu'il démarre, nous pouvons commencer à ajouter le nécessaire à notre `.drone.yml` : . Après s'être connecté à Sonarqube (`admin:admin`), nous pouvons aller générer un token, tel que décrit dans la [documentation du plugin Drone](http://plugins.drone.io/aosapps/drone-sonar-plugin/). Une fois la modification commitée et poussée, Drone enverra le code à Sonarqube qui en fera une analyse minutieuse. Rendez-vous sur pour admirer le résultat. ### Publier le binaire correspondant aux tags/jalons Nous savons maintenant que notre projet compile bien dans un environnement différent de celui du développeur ! Néanmoins, le binaire produit est perdu dès lors que la compilation est terminée, car nous n'en faisons rien. Ajoutons donc une nouvelle règle à notre `.droneci.yml` pour placer le binaire au sein de la liste des fichiers téléchargeables aux côtés des tags. Vous aurez sans doute besoin de : - - Attention à ne pas stocker votre clef d'API dans le fichier YAML ! ![Binaire publié automatiquement sur Gitea](tag-released.png){height=8cm} ::::: {.more} Lorsque l'on est plusieurs à travailler sur le projet ou pour accroître la sécurité, il convient de créer, un compte *bot* qui sera responsable de la création des *releases*. Ce sera donc sa clef d'API que l'on indiquera dans l'interface de Drone. :::::