Base de données
Git/GitLab
 est une forge logicielle open-source lancée en 2011.
Elle fournit une interface graphique pour créer des branches, des tags, des "pull requests" (appelées "merge requests"), les relire et les fusionner.
GitLab ne permet pas de créer de nouveaux groupes d'utilisateurs (les quatre possibles sont ceux par défaut), mais on peut inviter une personne sur un dépôt avec un autre groupe que celui qu'elle a ailleurs. Et il gère aussi des groupes d'applications dans lesquels un utilisateur peut avoir les mêmes droits.
CI/CD.
GitLab CI/CD est un outil d' et de , fourni avec la forge logicielle Gitlab.
Un pipeline est un ensemble de jobs déclenché automatiquement après différentes actions manuelles (git push, création de merge request, merge de branche, ou création de tag).
Ces jobs peuvent être lancés dans un certain ordre ou en parallèle, selon les étapes ("stages") auxquelles ils appartiennent.
IHM.
Dans le menu de gauche de GitLab, cliquer sur CI/CD pour voir les options :
.gitlab-ci.yml.
Pour qu'un pipeline se lance par hook dans un dépôt, il doit contenir un fichier .gitlab-ci.yml à la racine.
Exemple simple.
stages:
 - build
build-code:
 stage: build
 script:
 - echo "Hello World!"
 - pwd; ls -alh
before_script.
Script à exécuter avant chaque job.
variables.
Variables appelables plusieurs fois au sein du .gitlab-ci.yml. Certaines permettent de configurer le comportement de GitLab CI. Exemple :
GIT_STRATEGY.
Politique de clonage :
La valeur par défaut est définie dans l'IHM : /settings/ci_cd.
GIT_DEPTH.
Définit la profondeur lors du clone du dépôt : shallow clone.
Dans un job.
stage.
Étape qui lancera le job.
script.
Script à lancer.
only.
Liste des branches où le job peut s'exécuter (lors des merges).
Exemple complexe.
Voici le squelette d'un pipeline complet, dans lequel il faudrait remplacer les codice_1 par les vraies opérations :
stages:
 - build
 - test
 - publish
 - deploy
build:
 stage: build
 script:
 echo 'Build'
 except:
 refs:
 - tags
quality-check:
 stage: test
 script:
 echo 'Quality check'
 variables:
 GIT_STRATEGY: clone
 GIT_DEPTH: 1
 tags:
 - docker
 only:
 - branches
 except:
 refs:
 - tags
 - master
 - develop
run-test:
 stage: test
 script:
 echo 'Tests'
 variables:
 GIT_STRATEGY: clone
 GIT_DEPTH: 1
 tags:
 - docker
 only:
 - branches
 except:
 refs:
 - tags
 - master
 - develop
publish:
 stage: publish
 script:
 echo 'Publish artefact'
 variables:
 GIT_STRATEGY: none
 tags:
 - docker
 only:
 - master
 - develop
deploy:
 stage: deploy
 script:
 echo 'Deploy artefact on merge in master'
 rules:
 - if: $CI_COMMIT_BRANCH == "master"
 when: on_success
Debug.
Vérifier les valeurs des variables :
build-code:
 stage: build
 script:
 - export
Importation.
Il est possible d'incorporer des tâches de GitLab dans le pipeline, par exemple pour la sécurité :
sast:
 before_script: []
 stage: test
include:
 - template: Security/SAST.gitlab-ci.yml
Déploiements.
Déploiement de test à chaque Merge Request.
À chaque Merge Request (alias Pull Request, ou PR, ou MR), un job est créé pour lancer les instructions du .gitlab-ci.yml dans l'ordre. Mais avant de se lancer, il doit attendre la disponibilité d'un serveur de test sur lequel s'exécuter, appelé "runner".
Les runners peuvent être fournis par GitLab ou installés soi-même. Dans ce cas leur configuration se trouve dans un fichier .toml.
À partir d'une image Docker du registre.
Le principe consiste à envoyer une image Docker dans le registre GitLab pour que les conteneurs puissent l'utiliser ensuite sans avoir à le reconstruire.
$CI_REGISTRY_IMAGE représente l'URL du registre, ex : https://registry.gitlab.com/mon_espace.
Via Docker.
 image: docker:latest
Via Docker-compose.
Utile en cas de communication entre plusieurs conteneurs.
 image: docker/compose:1.27.4
Via Kaniko.
Si les conteneurs déployés le sont dans un autre conteneur, cela peut occasionner des problèmes de performances. Kaniko est un système pour éviter cela.
 image:
 name: gcr.io/kaniko-project/executor:debug

Précis d'épistémologie/Les dispositifs de mesure spatio-temporelle

Un règle rigide, ou un compas, permet de mesurer la distance entre ses extrémités en la comparant à d'autres distances. Une règle rigide est donc un dispositif de mesure d'une longueur, ou d'un intervalle, spatial. Le point important est que la règle soit rigide, pour que la distance mesurée soit toujours la même. On peut concevoir sur le même modèle des dispositifs de mesure des intervalles spatio-temporels. Une simple horloge est un tel dispositif. Elle permet de pointer deux événements qui sont toujours séparés par la même durée. On peut aussi se servir de deux horloges fixées à un même support rigide, chacune étant utilisée pour pointer un certain événement. Si le dispositif qui déclenche les deux horloges est régulier, l'intervalle spatio-temporel entre les deux événements pointés peut être toujours le même. De tels dispositifs permettent de mesurer l'espace-temps de la même façon que les règles rigides permettent de mesurer l'espace.
Un intervalle est du genre temps lorsqu'il est sur la trajectoire d'un point matériel massif. Il est du genre lumière lorsqu'il est sur la trajectoire d'un rayon de lumière dans le vide. Tous les autres intervalles sont du genre espace. Lorsqu'un intervalle est du genre espace, il existe toujours un repère inertiel pour lequel ses extrémités sont des événements simultanés. Les dispositifs de mesure spatio-temporels permettent de mesurer les trois genres d'intervalle. Une seule horloge suffit pour mesurer les intervalles du genre temps. Deux horloges fixées sur une règle rigide et convenablement synchronisées permettent de mesurer des intervalles du genre espace ou genre lumière.
Tous les intervalles du genre lumière sont égaux.
La théorie permet d'attribuer un nombre réel à tous les intervalles spatio-temporels, quel que soit leur genre, ou plus précisément à leur carré. Les intervalles du genre lumière en particulier sont tous égaux à zéro et donc tous égaux entre eux. C'est a priori surprenant. Cela veut dire par exemple que l'intervalle spatio-temporel entre l'émission d'un photon et sa réception trois mètres plus loin est égal à l'intervalle entre son émission et sa réception trois années-lumière plus loin, comme si le photon en avançant ne s'éloignait jamais de son point de départ. N'est-ce pas le pays des merveilles ?
Les dispositifs de mesure spatio-temporelle et le ralentissement des horloges permettent de comprendre ce résultat contre-intuitif. Imaginons une fusée lancée vers une étoile à trois années-lumière de la Terre. Un photon est émis à l'arrière de la fusée et il est reçu à l'avant, trois mètres plus loin, du point de vue de la fusée, donc une infime fraction de seconde plus tard. Mais à cause du ralentissement des horloges, ce qui dure une infime fraction de seconde du point de vue de la fusée peut durer trois années du point de vue de la Terre, pourvu que la fusée soit suffisamment rapide. Le même dispositif spatio-temporel mesure à la fois un intervalle lumière de trois années-lumière et un intervalle lumière de trois mètres. Il établit ainsi leur égalité.

Le système d'exploitation GNU-Linux/wget