Resolve "Dissociate release of Runtime and release of Client"

DOCUMENTATION OBSOLETE, REMPLACEE PAR CELLE DE !297 (merged)

Présentation de la feature

Réalisation découpée en deux parties :

• la présente MR pour la branche master afin de bénéficier du nouveau workflow pour la prochaine branche réseau de la ĞDev
• une branche network/gdev-800 avec un code un peu différent à cause des divergences intervenues sur master depuis

la branche network/gdev-800 sera adaptée après acceptation de la présente MR : comme il existe des différences, c'est difficile de réaliser le développement en parallèle et de répercuter les commits d'une branche vers l'autre. Donc je préfère qu'on acte le principe sur master d'abord puis que je fasse un rattrapage de la gdev-800 ensuite.

Fonctionnement général

A tout moment, il est possible de tirer depuis master une branche de la forme network/<nom_reseau>-<version_reseau>, par exemple network/gdev-900.

Pousser une telle branche déclenche un pipeline de cette forme :

A chaque commit, le même pipeline se présentera.

Seules deux actions sont possibles :

• trigger_client_release : permet de déclencher la release du Client
• trigger_network_release : permet de déclencher la release du Réseau

Le reste des jobs découle de l'action choisie.

trigger_network_release

Cette action déclenche le job g1_data qui consiste à générer le fichier genesis.json utilisé pour la génération des specs du réseau.

L'exécution réussie du job g1_data déclenche alors, conjointement au succès de build_runtime, le job build_specs qui construit le fichier de spec du réseau (gdev.json pour la ĞDev).

Enfin, l'exécution réussie de build_specs déclenche automatiquement l'exécution du job create_network_release qui crée la release du réseau <nom_reseau>-<version_reseau> (ex. gdev-900) contenant :

• le fichier de spec
• le fichier genesis.json
• le fichier de configuration de spec ( gdev.yml)
• le runtime initial présent dans le fichier de spec

Exemple :

trigger_client_release

Cette action peut être réalisée à chaque commit, et peut notamment être réalisée dans le même pipeline que la release du réseau (dans ce cas il faut simplement attendre que cette dernière soit pleinement terminée).

Prérequis :

• une milestone de la forme "runtime-<version>" (ex. : "runtime-900") utilisée pour créer la page de release en incluant les tickets et MR afférentes
• avoir déjà réalisé la release réseau au moins une fois
• ne pas avoir déjà réalisé la release du Client pour la même version du runtime

Cette action déclenche le job build_raw_specs qui va télécharger les specs de la release de réseau préalablement produite et générer les raw specs en incluant le fichier de clientSpec ( gdev_client-specs.yml par exemple).

En cas de succès, alors deux jobs sont déclenchés en parallèle :

• create_client_release qui va produire la page de release "<reseau>-<version_du_runtime>-<version_du_client>" (ex. gdev-900-0.8.0)

• docker_deploy qui va produire les tags sur dockerhub :

---

Closes #195 (closed)

docker/Dockerfile

@@ -11,10 +11,15 @@ FROM --platform=$BUILDPLATFORM rust:1-bullseye as build
 ARG BUILDPLATFORM
 ARG TARGETPLATFORM
 
+# Debug
+RUN echo "BUILDPLATFORM = $BUILDPLATFORM"
+RUN echo "TARGETPLATFORM = $TARGETPLATFORM"
+
 # We need the target arch triplet in both Debian and rust flavor
 RUN echo "DEBIAN_ARCH_TRIPLET='$(dpkg-architecture -A${TARGETPLATFORM#linux/} -qDEB_TARGET_MULTIARCH)'" >>/root/dynenv
 RUN . /root/dynenv && \
     echo "RUST_ARCH_TRIPLET='$(echo "$DEBIAN_ARCH_TRIPLET" | sed -E 's/-linux-/-unknown&/')'" >>/root/dynenv
+RUN cat /root/dynenv
 
 WORKDIR /root
 
@@ -91,5 +96,9 @@ USER duniter
 
 # Intall
 COPY --from=build /root/build /usr/local/bin/
+COPY --from=build /root/dynenv /var/lib/duniter
 COPY docker/docker-entrypoint /usr/local/bin/
 COPY docker/docker-distance-entrypoint /usr/local/bin/
+
+# Debug
+RUN cat /var/lib/duniter/dynenv