mymarvin

my_marvin est un projet Epitech (Tek4, module B-DOP-400) qui consiste a configurer entierement une instance Jenkins via Configuration as Code (JCasC) et Job DSL, sans jamais toucher a l'interface graphique. L'objectif est de decrire dans un unique fichier YAML my_marvin.yml la totalite de l'etat souhaite de l'instance : message systeme, controle d'acces Agent -> Master, utilisateurs, strategie d'autorisation et dossiers. Aucun mot de passe ne doit apparaitre en clair : chaque identifiant est recupere depuis une variable d'environnement dediee (USER_CHOCOLATEEN_PASSWORD, USER_VAUGIE_G_PASSWORD, etc.), toute violation entrainant l'echec automatique du projet.

La gestion des droits repose sur une strategie basee sur les roles (role-based authorization strategy) avec quatre roles globaux strictement definis : admin (toutes les permissions, assigne a Hugo), ape (build et consultation des workspaces, assigne a Jeremy), gorilla (permissions de ape plus creation/configuration/suppression/deplacement de jobs et annulation de builds, assigne a Garance) et assist (lecture seule des jobs et workspaces, assigne a Nassim). Chaque role ne doit recevoir que les permissions explicitement listees dans le sujet, sans permission superflue, ce qui impose de bien connaitre la granularite du plugin role-strategy plutot que d'accorder des droits par facilite.

Un dossier racine Tools regroupe deux jobs freestyle : clone-repository, qui clone un depot Git dont l'URL est passee en parametre via une seule commande shell, et SEED, qui recoit un nom de depot GitHub et un nom d'affichage puis genere dynamiquement un nouveau job via l'execution d'un script job_dsl.groovy centralise a la racine du repository. Les jobs crees par SEED sont places a la racine, lies au depot GitHub donne (a la fois pour la propriete GitHub project et pour le SCM Git, idealement via une seule expression reutilisant le parametre GITHUB_NAME), et declenches soit manuellement soit par un polling SCM toutes les minutes.

Chaque job genere effectue un nettoyage de workspace avant build (ws-cleanup) puis enchaine quatre etapes shell separees : make fclean, make, make tests_run et make clean, ce qui permet de valider automatiquement n'importe quel projet Epitech pousse sur GitHub. L'instance de test n'installe qu'un ensemble restreint de plugins (cloudbees-folder, configuration-as-code, credentials, github, job-dsl, script-security, structs, role-strategy, ws-cleanup) : utiliser un plugin non liste fait echouer toute la correction DSL, ce qui impose de rester strictement dans le perimetre impose plutot que d'ajouter des plugins de confort.