Aller au contenu

Guide d'Ingénierie : Architecture Hybride de Test Multiplateforme (GitLab CI & Exécution Déportée OIDC)

Navigation : Documentation > Architecture Hybride Multiplateforme
Contexte : Ce document détaille l'architecture d'intégration continue permettant de valider nativement sur matériel réel le cycle de vie des paquets Érable sur Linux (ARM64 & x86_64), Windows (x86_64) et macOS (Apple Silicon & Intel) de manière sécurisée par OpenID Connect (OIDC Zero-Trust).

Sommaire

  1. Problématique : Limites de l'Émulation Logicielle Inter-Architectures
  2. Architecture Hybride Distribuée (GitLab CI & Exécuteurs Déportés)
  3. Matrice des Architectures Supportées
  4. Note Formelle : Gestion des Architectures Spécifiques
  5. Authentification OIDC Zero-Trust sans Secrets Statiques
  6. Protocole de Test du Cycle de Vie des Paquets

1. Problématique : Limites de l'Émulation Logicielle Inter-Architectures

Dans un environnement d'intégration continue conteneurisé, tester simultanément des binaires compilés pour des architectures et systèmes hétérogènes (Windows x86_64, Linux ARM64, macOS Apple Silicon) soulève une contrainte majeure :

  1. Incompatibilité du Jeu d'Instructions CPU (ISA) : La virtualisation matérielle accélérée (KVM) ne fonctionne qu'entre architectures identiques. Pour exécuter du code x86_64 sur un processeur ARM64 (ou inversement), un hyperviseur comme QEMU est contraint d'opérer en mode TCG (Tiny Code Generator) (émulation logicielle pure).
  2. Latence Inacceptable : Le démarrage d'une machine virtuelle invitée en émulation logicielle pure requiert entre 30 et 60 minutes, provoquant l'interruption prématurée (timeout) des pipelines d'intégration continue.
  3. Absence d'Hyperviseur Imbriqué (Nested Virtualization) : La majorité des environnements conteneurisés en cloud ne permettent pas d'exposer un périphérique /dev/kvm complet.

Conclusion d'ingénierie : L'émulation logicielle croisée étant inadaptée aux exigences de réactivité d'Érable, la validation multiplateforme doit impérativement s'exécuter sur du matériel natif bare-metal ou VMs spécialisées dédiées.

2. Architecture Hybride Distribuée (GitLab CI & Exécuteurs Déportés)

Pour garantir des tests d'exécution 100% réels sur matériel natif sans surcoût, l'architecture sépare l'orchestration centrale et l'exécution matérielle distribuée :

flowchart TD
    subgraph GITLAB ["GitLab CI/CD (Orchestrateur Central)"]
        DISCOVER["discover_issues / process_issue"]
        RUNNER_LINUX["Runner CI Dédié (Linux ARM64)"]
        JOB_ARM["Test Natif ARM64 Linux<br/>(erable install/exec/uninstall)"]
        JOB_TRIGGER["Job trigger_matrix<br/>(Génération Jeton JWT OIDC)"]
    end

    subgraph RUNNERS ["Exécuteurs Déportés Multi-OS"]
        OIDC_AUTH["Vérification Jeton OIDC GitLab<br/>(Zero-Trust, 0 Secret Statique)"]

        subgraph MATRIX ["Matrice Native Multiplateforme"]
            M_L64["Linux x86_64 (ubuntu-latest)"]
            M_W64["Windows x86_64 (windows-latest)"]
            M_M_ARM["macOS Apple Silicon (macos M-series)"]
            M_M_X64["macOS Intel (macos x86_64)"]
        end
    end

    DISCOVER --> RUNNER_LINUX
    RUNNER_LINUX --> JOB_ARM
    DISCOVER --> JOB_TRIGGER
    JOB_TRIGGER -.->|"Appel API Sécurisé + Jeton OIDC"| OIDC_AUTH
    OIDC_AUTH --> MATRIX
  • L'Orchestrateur GitLab CI conserve son rôle central pour compiler les trampolines Linux et exécuter nativement les tests aarch64-linux.
  • Les Exécuteurs Distribués prennent en charge en parallèle l'ensemble des cibles Windows et macOS sur des environnements natifs adaptés.

3. Matrice des Architectures Supportées

Architecture Cible Système Hôte Type d'Exécuteur Environnement Type d'Exécution
aarch64-linux Linux ARM64 GitLab Runner Dédié Conteneur Docker natif Natif direct (0ms)
x86_64-linux Linux x86_64 Exécuteur Distribué VM Ubuntu Server Natif direct
x86_64-windows Windows x86_64 Exécuteur Distribué VM Windows Server Natif direct (PowerShell)
aarch64-macos macOS Apple Silicon Exécuteur Distribué VM macOS Sonoma Natif direct (Zsh)
x86_64-macos macOS Intel Exécuteur Distribué VM macOS Ventura Natif direct (Zsh)

4. Note Formelle : Gestion des Architectures Spécifiques

[!NOTE] Windows ARM64 (aarch64-windows) :
L'architecture Windows on ARM ne disposant pas actuellement de runners bare-metal standardisés dans les flottes d'intégration continue publiques gratuites, les paquets ciblant cette architecture sont validés statiquement par audit d'intégrité cryptographique SHA-256 et linter AST.

5. Authentification OIDC Zero-Trust sans Secrets Statiques

La communication entre l'orchestrateur GitLab CI et les exécuteurs de test repose exclusivement sur le protocole OpenID Connect (OIDC) :

  1. Jeton Éphémère Signé Cryptographiquement : GitLab génère à la volée un jeton d'identité JWT signé par la clé privée de la forge (id_tokens.GITLAB_OIDC_TOKEN).
  2. Zéro Secret Statique : Aucun mot de passe ni token d'accès permanent à longue durée de vie n'est stocké dans les variables du dépôt.
  3. Validation de l'Audience & Sujet : L'exécuteur distant vérifie cryptographiquement que le jeton provient strictement de la branche légitime du projet Érable avant de débloquer le pipeline de test.

6. Protocole de Test du Cycle de Vie des Paquets

Chaque paquet soumis subit une épreuve complète en 5 étapes successives sur chaque OS cible :

  1. Téléchargement & Vérification d'Empreinte : Contrôle rigoureux de la somme de contrôle SHA-256.
  2. Extraction Atomique : Décompression dans un répertoire isolé packages/<nom>/<version>/.
  3. Mise en Place du Routage : Déploiement des trampolines binaires et du fichier pointeur .target.
  4. Test d'Exécution Fonctionnel : Invocation réelle de la commande avec le paramètre de version (ex: jq --version) pour vérifier l'absence d'erreur dynamique (DLL not found, segmentation fault).
  5. Désinstallation Hermétique : Exécution de erable uninstall et vérification de la purge intégrale sans résidus.