|
|
[:arrow_backward: Configurer la sécurité d'un projet](Configurer%20la%20s%C3%A9curit%C3%A9%20d'un%20projet)
|
|
|
|
|
|
[[_TOC_]]
|
|
|
|
|
|
## _Runners_
|
|
|
|
|
|
[Documentation officielle](https://docs.gitlab.com/ce/ci/README.html)
|
|
|
|
|
|
Le fonctionnement de Gitlab CI pour l’intégration continue est basé sur les _runners_, qui sont des logiciels qui vont récupérer les tâches d’exécution de la construction d’un projet donné.
|
|
|
|
|
|
Ces _runners_ peuvent être installés sans contraintes sur un serveur extérieur à Gitlab, par exemple dans l'infrastructure d'un laboratoire.
|
|
|
|
|
|
La communication entre un _runner_ et l’instance Gitlab se fait dans le sens _runner_ vers Gitlab, et utilise HTTPS.
|
|
|
|
|
|
Ces _runners_ installés sont hors du périmètre d’exploitation de cette forge, et sont sous la responsabilité des personnes qui l’installent et le connectent à Gitlab.
|
|
|
|
|
|
### Installation d’un runner
|
|
|
|
|
|
Pour un installer un runner, il suffit de choisir la [méthode la plus adaptée](https://docs.gitlab.com/runner/install/) (binaire, image docker, paquet RPM/DEB, ...).
|
|
|
|
|
|
### Configuration d’un runner
|
|
|
|
|
|
Pour connecter le runner à l’instance Gitlab, il suffit de suivre la [documentation officielle](https://docs.gitlab.com/runner/register/) qui est complète.
|
|
|
|
|
|
## Fichier `.gitlab-ci.yml`
|
|
|
|
|
|
La description de la construction du projet se base sur le fichier `.gitlab-ci.yml` présent à la racine du projet. Une [description rapide](https://docs.gitlab.com/ee/ci/yaml/gitlab_ci_yaml.html) est présente sur le site de Gitlab, ainsi que la [syntaxe complète](https://docs.gitlab.com/ee/ci/yaml/README.html) de ce fichier.
|
|
|
|
|
|
Le contenu de ce fichier diffère non seulement en fonction des langages utilisés, des tâches que l'on souhaite faire, mais aussi de l'architecture réseau (utilisation d'un proxy, url d'autres composants, ...)
|
|
|
|
|
|
Le principe de base est de faire exécuter une suite de commandes shell afin d'effectuer les différentes étapes de la construction (compilation, test, déploiement, ...)
|
|
|
|
|
|
Afin de pouvoir exécuter aussi bien de la compilation C/Rust/Java/..., déclencher des tests avec Maven/NPM/..., le plus simple est d'utiliser des images Docker qui mettent à disposition un environnement contenant le nécessaire pour ces actions.
|
|
|
|
|
|
Par exemple, pour compiler du Java, on utilisera une image Docker [openjdk](https://hub.docker.com/r/adoptopenjdk/openjdk11), alors que pour un projet Angular on utilisera l'image Docker [node](https://hub.docker.com/_/node).
|
|
|
|
|
|
On peut tout à fait utiliser plusieurs images dans une même phase de construction : compilation du _frontend_ Angular avec l'image node, et compilation du _backend_ avec l'image openjdk.
|
|
|
|
|
|
## Déclenchement de la construction
|
|
|
|
|
|
Par défaut, la CI de Gitlab se déclenche à chaque événement. Il est possible de définir de manière très fine quand une construction doit se déclencher en utilisant le mot-clé `rules` (à préférer aux mots-clés `only`/`except` qui sont dépréciés).
|
|
|
|
|
|
La variable `CI_PIPELINE_SOURCE` est automatiquement renseignée et permet déjà de connaitre l'événement déclencheur et donc de ne lancer la construction que sur certains de ces événements, par exemple :
|
|
|
| Règle | Description |
|
|
|
|-------|-------------|
|
|
|
| `if: '$CI_PIPELINE_SOURCE == "push"'` | uniquement sur les _push_ de branches ou tags |
|
|
|
| `if: '$CI_PIPELINE_SOURCE == "merge_request_event"'` | uniquement sur les créations ou modifications de _merge requests_ |
|
|
|
| `if: '$CI_PIPELINE_SOURCE == "schedule"'` | uniquement sur les constructions planifiées |
|
|
|
|
|
|
> Voir ce lien pour plus d'exemples : <https://docs.gitlab.com/ee/ci/yaml/README.html#common-if-clauses-for-rules>
|
|
|
|
|
|
Il est possible d'utiliser d'[autres variables](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html), et de faire des expressions régulières :
|
|
|
|
|
|
```yaml
|
|
|
rules:
|
|
|
# Si la branche commence par feature
|
|
|
- if: $CI_COMMIT_REF_NAME =~ /^feature/
|
|
|
```
|
|
|
|
|
|
Avec [`rules:changes`](https://docs.gitlab.com/ee/ci/yaml/README.html#ruleschanges) et [`rules:exists`](https://docs.gitlab.com/ee/ci/yaml/README.html#rulesexists) il est possible de faire des règles assez évoluées.
|
|
|
|
|
|
Il ne faut pas hésiter à se référer à la [documentation officielle de `rules`](https://docs.gitlab.com/ee/ci/yaml/README.html#rules) pour plus de détails et d'exemples.
|
|
|
|
|
|
## Templates
|
|
|
|
|
|
Gitlab propose de [nombreux templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates).
|
|
|
|
|
|
## Astuces
|
|
|
|
|
|
### Ne pas déclencher la construction
|
|
|
|
|
|
Il est possible de faire en sorte que la construction ne se déclenche pas alors qu'elle devrait. Il suffit pour cela d'ajouter dans le message de commit le texte suivant : `[ci skip]` ou `[skip ci]`.
|
|
|
|
|
|
Source : <https://docs.gitlab.com/ee/ci/yaml/index.html#skip-pipeline>
|
|
|
|
|
|
---
|
|
|
|
|
|
[:arrow_backward: Configurer la sécurité d'un projet](Configurer%20la%20s%C3%A9curit%C3%A9%20d'un%20projet) |
|
|
\ No newline at end of file |