Prise en charge des builds multi-référentiels dans Space Automation
Nous avons récemment ajouté de nouvelles fonctionnalités à Space Automation (la partie de JetBrains Space responsable de l’intégration et du déploiement continus) qui permettent à vos scripts d’automatisation de fonctionner avec plusieurs référentiels Git.
Voici en résumé ce qui a changé :
-
Une tâche (job) peut maintenant copier n’importe quel référentiel au sein du projet (pas seulement celui qui contient le script d’automatisation en cours).
-
L’automatisation peut désormais déclencher l’exécution d’une tâche en cas de changements dans un référentiel, une branche, un répertoire ou un fichier.
Dans quels cas est-ce utile ? Par exemple, vous avez un projet basé sur des microservices (chacun dans un référentiel séparé) et un référentiel séparé avec des tests d’intégration qui s’exécutent dans tout le projet. Un autre exemple concret : un projet qui se compose de plusieurs référentiel, chaque référentiel ayant son propre dossier doc/ avec sa documentation. En utilisant Automation, vous pouvez configurer une tâche qui suit les changements dans les dossiers doc/ de tous ces référentiels, construit et un site web de documentation interne et le déploie.
Poursuivez votre lecture pour en savoir plus !
Copier du code source
Normalement, dans Space Automation, vous n’avez pas à copier "de code source". Chaque fois qu’une tâche est lancée, Automation clone la branche actuelle du référentiel qui contient le script en cours d’exécution.
Maintenant, si une tâche requiert du contenu d’un autre référentiel dans un projet, vous pouvez copier de ce référentiel en plus du référentiel principal. Il vous suffit de spécifier le nom du second référentiel dans le bloc git :
job("check out second repo") {
// check out second-repo to /mnt/space/work/repo-2
git("second-repository") {
// the default path is /mnt/space/work/$repoName
// but you can change it with cloneDir
cloneDir = "repo-2"
}
container("ubuntu") {
shellScript {
content = """
echo Directory structure
ls -R /mnt
echo Working dir is
pwd
"""
}
}
}
// the /mnt/space/work dir will contain the current and the second repo
// /mnt/space/work/main-repo ; /mnt/space/work/repo-2
// Working dir is /mnt/space/work/main-repoCe n’est pas tout ! Maintenant, vous avez également choisir quelles données du référentiel vous voulez récupérer : vous pouvez ainsi extraire des balises, des branches spécifiques ou des révisions. Vous trouverez plus d’informations à ce sujet dans la documentation sur Automation
Déclencher l’exécution d’une tâche en cas de changements dans une branche, un dossier ou un fichier
Par défaut, lorsqu’un commit est poussé vers une branche spécifique du référentiel, Automation déclenche l’exécution d’un script dans cette branche. Évidemment, cela fonctionne pour toutes les branches du référentiel. Pour exécuter le script uniquement dans certains référentiels, utilisez le paramètre branchFilter à l’intérieur du bloc gitPush.
Par exemple, pour déclencher des tâches uniquement dans la branche my-feature :
job("Run on git push") {
startOn {
gitPush {
branchFilter {
+"refs/heads/my-feature"
}
}
}
}Notez que branchFilter prend en charge Regex, les règles d’exclusion et d’inclusion et les métacaractères.
Pour déclencher l’exécution d’une tâche en cas de modification des fichiers et des dossiers, utilisez le bloc pathFilter (comme branсhFilter, il prend en charge la création de filtres complexes) :
job("Run on git push") {
startOn {
gitPush {
pathFilter {
// include all from 'targets' directory
+"targets/**"
// exclude 'targets/main' directory
-"targets/main/**"
// include all 'Main.kt' files in the project
// As this rule is more specific,
// 'Main.kt' will be included even if
// it's located in 'targets/main'
+"**/Main.kt"
}
}
}
}Déclencher l’exécution d’une tâche en cas de changements dans un autre dossier
Il peut arriver que vous ayez besoin de configurer un build qui utilise le code source de plusieurs référentiels de projets. Par exemple, vous pouvez créer un référentiel séparé qui contiendra le script de build pour l’ensemble du projet tandis que les autres référentiels n’auront aucun fichier .space.kts.
Prenons l’exemple le plus simple possible. Disons que vous avez un projet avec deux référentiels : first-repository et second-repository. Vous ajoutez le fichier .space.kts suivant au référentiel first-repository :
job("Run on change in second-repository") {
startOn {
gitPush {
repository = "second-repository"
}
}
// don't forget to check out
// the content of second-repo
git("second-repository")
container("alpine") {
shellScript {
content = "ls /mnt/space/work"
}
}
}Comment cela se présente-t-il dans l’interface utilisateur ? Si vous ouvrez la page Jobs pour first-repository, vous ne verrez rien de nouveau, juste une exécution normale de la tâche :
Mais si vous passez à la liste des tâches pour second-repository, vous verrez qu’elle comprend des tâches cross-référencées – des tâches d’autres référentiels liées au référentiel actuellement sélectionné. Dans notre cas, cette tâche est celle du first-repository :
Bien sûr, vous pouvez aller plus loin et ajouter un niveau supplémentaire au déclencheur du référentiel : filtrer par une branche ou un chemin. Retrouvez plus de détails dans la documentation pour Automation.
N’hésitez pas à nous faire part de vos commentaires et à essayer ces nouvelles fonctionnalités !
Auteur de l’article original en anglais : Alexey Totin
Subscribe to Space Blog updates
