Space est un environnement de travail collaboratif intégré tout-en-un et extensible pour la gestion des projets et des équipes. Développée par JetBrains, la solution centralise l'ensemble des outils, informations et communications, afin d’améliorer l’efficacité de la collaboration au sein des équipes et globalement entre les différentes équipes de l'entreprise. Space Automation est le composant qui permet aux équipes de développement logiciel d’exécuter les tâches d’intégration et de livraison continues dans Space, pour construire, tester et déployer leurs projets.
JetBrains a récemment ajouté de nouvelles fonctionnalités à Space Automation qui permettent à vos scripts d’automatisation de fonctionner avec plusieurs référentiels Git. 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. En outre, Automation 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.
Ces nouveautés sont utiles, par exemple, lorsque 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érentiels, 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 un site web de documentation interne et le déploie.
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 courante 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 :
| Code shell : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
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-repo |
Mais ce n’est pas tout. Maintenant, vous pouvez é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.
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 :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 |
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) :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
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 référentiel
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 :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
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 :
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. Vous trouverez plus de détails dans la documentation pour Automation.
En savoir plus sur ces fonctionnalités Tester Space gratuitement