Implémentation Avancée

Voici une explication de l’implémentation avancée du CI/CD, utilisant des traitements et des outils plus détaillés. main fonctionne de la même façon que dans la version racine ; les traitements build et test proviennent du fichier advanced.mel et contiennent l’implémentation CI/CD.

Implémentation CI/CD

Les traitements build et test sont implémentés de la même façon : ils nécessitent de configurer un runner sur lequel les étapes sont distribuées. Leur implémentation de base est donnée comme exemple fonctionnel simple.

Ils prennent tous les deux le modèle CicdDispatchEngine et un signal d’entrée trigger. CicdDispatchEngine et l’entrée trigger sont utilisés pour demander un nouveau runner distribué CicdRunnerEngine via setupRunner dès que c’est utile.


treatment build[cicd: CicdDispatchEngine](repository_clone_url: string, repository_clone_ref: string)
  model runner: CicdRunnerEngine()
  input trigger: Block<void>
  output data:   Stream<byte>
{
    setupRunner[
        dispatcher=cicd,
        runner=runner
    ](
        name="build",
        cpu=100, // mCPU
        memory=500, // MB
        storage=1000, // MB
        volumes=[
            // Volumes mis à disposition
            |volume("build-result", 30 /* MB */)
        ],
        containers=[
            |container("ubuntu", // Nom du conteneur
                1000, // mCPU
                200, // MB
                8000, // MB
                |amd64(),
                [ // Points de montage
                    |mount("build-result", "/mounted/result")
                ],
                "ubuntu:noble", // Nom de l'image
                _)
        ]
    )
    gitClone: stepOn[runner=runner](
        executor_name="ubuntu", // Utilise le conteneur "ubuntu"
        environment=|wrap<Environment>(|environment(|map([/* Pas de variables d'env */]), "/root", false, false)),
        commands=[
            |command("apt-get", ["update"]),
            |command("apt-get", ["install", "-y", "git"]),
            |command("git", ["config", "--global", "url.https://.insteadOf", "git://"]),
            |command("git", ["clone", "--branch", repository_clone_ref, "--depth", "1", repository_clone_url, "project"])
        ]
    )
    makeList: stepOn[runner=runner](
        executor_name="ubuntu", // Utilise le conteneur "ubuntu"
        environment=|wrap<Environment>(|environment(|map([]), "/root/project", false, false)),
        commands=|raw_commands([
            "sh -c \"ls -l --almost-all | tee files-list.txt\"",
            "mv files-list.txt /mounted/result/"
        ]),
        out_filesystem="build-result",
        out_file="files-list.txt"
    )
    stopRunner[runner=runner]()
 
    Self.trigger -> setupRunner.trigger,ready -> gitClone.trigger,completed -> makeList.trigger,finished -> stopRunner.trigger
                                                                               makeList.data -------------> Self.data
}

Configurer le runner

setupRunner prend différents paramètres, dont les principaux sont :

name, une chaîne avec laquelle tous les logs seront marqués ;
memory, mémoire (en mébioctets) dédiée au moteur Mélodium ;
cpu, quantité de CPUs (en millicores) que le moteur Mélodium doit avoir ;
storage, espace disque (en mébioctets) dont dispose le moteur Mélodium ;
volumes, tableau de volumes que le moteur Mélodium et les conteneurs peuvent partager sur le runner ;
containers, liste de conteneurs disponibles pour exécuter des étapes sur le runner.

Les volumes sont essentiellement des labels associés à une taille (en mébioctets), et peuvent être montés dans les conteneurs pour partager des données avec eux. Les conteneurs sont définis comme suit :


|container(name, memory, cpu, storage, arch, mounts, image, pull_secret)

name étant le nom désigné avec lequel le conteneur peut être adressé comme exécuteur ;
memory, cpu et storage ayant la même signification que pour le moteur Mélodium ;
arch désignant l’architecture matérielle sur laquelle le conteneur doit s’exécuter ;
mounts étant un tableau de points de montage pour les volumes définis dans le système de fichiers du conteneur ;
image l’image de conteneur à utiliser comme base ;
pull_secret le secret (optionnel) à utiliser pour récupérer l’image de conteneur.

Le moteur Mélodium lui-même peut être assez économe en ressources car le travail en CI/CD est généralement effectué dans des conteneurs, ne laissant que l’orchestration et le streaming de données. Ainsi, 0,1 CPU et 100 Mio sont de bonnes valeurs par défaut.

Actuellement les architectures AMD64/x86_64 |amd64() et ARM64/aarch64 |arm64() sont supportées, et tous les conteneurs dans un même runner doivent utiliser la même architecture.

Tous les volumes montés dans les conteneurs doivent tenir dans le stockage du conteneur lui-même. Alors que les valeurs de CPU et mémoire sont cumulatives entre le moteur principal et les conteneurs, l’espace de stockage correspondant aux volumes est partagé et non dupliqué entre les conteneurs.

Exécuter des étapes

Sur chaque runner, un nombre arbitraire d’étapes peut être appliqué en utilisant les traitements stepOn et stepOnWithInput. Ces traitements prennent un CicdRunnerEngine sur lequel le travail sera effectué, selon la logique suivante :

réception du fichier de données en entrée (pour stepOnWithInput),
traitement des commandes,
émission du fichier de données en sortie.

Données en entrée

stepOnWithInput dispose de deux paramètres configurant quel fichier est écrit : in_filesystem et in_file indiquent respectivement quel volume et quel nom de fichier sont remplis avec les données provenant de l’entrée data.

Ici le fichier "list.txt" est écrit sur le volume "tested-data" et accessible au point de montage "/mounted/data/" de l’exécuteur "alpine" :


makeTest: stepOnWithInput[runner=runner](
    executor_name="alpine",
    in_filesystem="tested-data",
    in_file="list.txt",
    commands=[
        |command("test", ["-s", "/mounted/data/list.txt"]),
        |command("cat", ["/mounted/data/list.txt"])
    ]
)

Traitement des commandes

Le paramètre commands est une liste de commandes exécutées sur l’exécuteur désigné par executor_name, dans un environment optionnellement défini.

Les commandes peuvent être spécifiées de plusieurs façons :

fonction |command(), pour une commande détaillée avec liste d’arguments ;
fonction |raw_command(), pour une commande en chaîne brute ;
fonction |raw_commands(), pour une liste complète de commandes en chaîne.

environment peut également être fourni pour spécifier des variables d’environnement supplémentaires ou le répertoire de travail. L’environnement est appliqué à toutes les commandes d’une étape donnée.


gitClone: stepOn[runner=runner](
    executor_name="ubuntu",
    environment=|wrap<Environment>(|environment(|map([]), "/root", false, false)),
    commands=[
        |command("apt-get", ["update"]),
        |command("apt-get", ["install", "-y", "git"]),
        |command("git", ["config", "--global", "url.https://.insteadOf", "git://"]),
        |command("git", ["clone", "--branch", repository_clone_ref, "--depth", "1", repository_clone_url, "project"])
    ]
)

Données en sortie

Les traitements stepOn et stepOnWithInput permettent tous deux de sortir des données. out_filesystem et out_file spécifient quel volume et quel fichier sont streamés après les commandes de l’étape.

Ici le fichier "files-list.txt" est streamé depuis le volume "build-result" après l’exécution des commandes :


makeList: stepOn[runner=runner](
    executor_name="ubuntu",
    environment=|wrap<Environment>(|environment(|map([]), "/root/project", false, false)),
    commands=|raw_commands([
        "sh -c \"ls -l --almost-all | tee files-list.txt\"",
        "mv files-list.txt /mounted/result/"
    ]),
    out_filesystem="build-result",
    out_file="files-list.txt"
)

Exécuter le CI/CD localement

Pour exécuter le programme CI/CD, invoquez Mélodium avec les paramètres du programme :


melodium run .melodium-ci/Compo.toml advanced --api_token <VOTRE_TOKEN_RUN_API> --output_directory /votre/répertoire/de/sortie --repository_clone_url <URL_CLONE_COMPLETE>.git --repository_clone_ref <BRANCHE_OU_TAG>

Où VOTRE_TOKEN_RUN_API est un token Run de Cadence.CI. Cela exécute le “moteur principal” du CI/CD depuis l’ordinateur local et distribue le travail sur des workers distants.

Tous les logs CI/CD sont affichés dans le terminal, et les données sont écrites dans /votre/répertoire/de/sortie.

Template CI/CD Installer la compétence Mélodium