L'intégration continue : le serveur et ses runners
La mécanique d'un serveur d'intégration continue comme GitLab CI ou GitHub Actions : déclencheurs, runners, cache et artefacts, secrets masqués, builds reproductibles et branches protégées.
- 27 cartes
- 4 thèmes
- Gratuit
Le programme, thème par thème
Le poids de chaque thème suit celui que lui donne l'examen.
- Notions
- Questions
- Ranger et relier
- Mises en situation
Quelques cartes du deck
Intégration continue : de quoi s'agit-il ?
Voir la réponse
Pratique qui consiste à fusionner souvent son travail dans la branche commune, chaque fusion déclenchant automatiquement une construction et des tests.
Plus on fusionne souvent, plus les conflits et les régressions sont petits et faciles à trouver : le serveur dit en quelques minutes si le changement casse quelque chose.
Avec cette règle, un développeur pousse un commit sur sa branche
fix-login, sans ouvrir de demande de fusion. Que se passe-t-il ?
```yaml
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_COMMIT_BRANCH == "main"`- Aucun pipeline ne démarre
- Un pipeline démarre, comme pour toute poussée
- Un pipeline démarre, mais sans les jobs de test
- Le serveur refuse la poussée
Voir la réponse
Aucun pipeline ne démarre
Les deux règles se lisent dans l'ordre et la première qui est vraie décide. Une poussée sur
fix-loginn'est ni un événement de demande de fusion ni surmain: aucune règle ne correspond, donc pas de pipeline.Le runner confie chaque job à un …, qui décide où il tourne : le plus souvent un conteneur créé pour l'occasion puis détruit, ce qui évite que deux jobs se polluent.
Voir la réponse
Le runner confie chaque job à un exécuteur, qui décide où il tourne : le plus souvent un conteneur créé pour l'occasion puis détruit, ce qui évite que deux jobs se polluent.
Un job qui part d'un environnement vierge montre ce qui manque vraiment : aucun fichier oublié sur un poste ne le fait réussir à tort. L'exécuteur shell, lui, lance le job directement sur la machine du runner, sans cette isolation.
Déclencheur de pipeline : de quoi s'agit-il ?
Voir la réponse
Événement qui lance une exécution : poussée de commits, demande de fusion, étiquette, planification ou lancement manuel.
Un pipeline ne part pas tout seul : une règle dit pour quels événements et quelles branches il s'exécute. Sans règle adaptée, une demande de fusion peut n'être jamais testée.
Les tests passent sur le poste du développeur et échouent sur le serveur, avec une erreur de syntaxe dans une dépendance. Quelle correction traite la cause ?
- Relancer le job plusieurs fois jusqu'à ce qu'il finisse par passer
- Épingler l'image du job et verrouiller les versions des dépendances
- Désactiver les tests sur le serveur et ne les lancer qu'en local
- Vider le cache du serveur avant chaque job pour repartir de zéro
Voir la réponse
Épingler l'image du job et verrouiller les versions des dépendances
Le poste et le serveur n'ont pas les mêmes versions du langage ou des dépendances. Image épinglée et fichier de verrouillage donnent partout le même environnement. Relancer ou couper les tests cache le problème.