CI/CD with GitHub Actions & DevOps Pipelines · Leçon

Flux de travail entre dépôts

Apprenez à enchaîner des flux de travail entre différents dépôts pour gérer les dépendances et orchestrer des déploiements complexes.

Flux de travail entre dépôts est une leçon CI/CD with GitHub Actions & DevOps Pipelines gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage CI/CD with GitHub Actions & DevOps Pipelines, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours CI/CD with GitHub Actions & DevOps Pipelines comprend 4 leçons au total.

Introduction aux flux de travail inter-dépôts

Dans le développement logiciel moderne, les applications se composent souvent de plusieurs composants répartis dans différents dépôts. Pensez aux microservices, aux bibliothèques partagées ou aux configurations de déploiement distinctes.

L'orchestration de flux de travail entre ces dépôts distincts offre davantage de modularité et une meilleure séparation des responsabilités. Cette leçon explique comment y parvenir avec GitHub Actions.

Pourquoi orchestrer des flux entre dépôts ?

Traditionnellement, la portée des flux de travail GitHub Actions est limitée à un seul dépôt. Mais que faire si vous avez besoin :

De générer un artefact dans un dépôt et de déclencher un déploiement dans un autre ?
D'utiliser un dépôt de configuration partagé pour déclencher des mises à jour dans plusieurs dépôts de services ?
D'imposer à tous les autres dépôts des règles de sécurité gérées dans un dépôt central ?

Les flux de travail inter-dépôts apportent une solution à ces scénarios complexes.

Connecter les dépôts : `repository_dispatch`

GitHub Actions propose un type d'événement spécial appelé repository_dispatch. Il agit comme une notification web personnalisée pour vos dépôts GitHub.

Un flux de travail (l'« expéditeur ») envoie une requête API à GitHub.
Un autre flux de travail (le « récepteur »), situé dans un dépôt différent, écoute cet événement précis.

Cela permet de déclencher par programmation des flux de travail entre différents dépôts.

Configurer le flux de travail récepteur

Pour recevoir un événement repository_dispatch, un flux de travail du dépôt cible doit être configuré pour l'écouter. Cette configuration s'effectue à l'aide du mot-clé on:.

Voici à quoi pourrait ressembler un flux de travail dans repo-B :

name: Receive Dispatch Event

on:
  repository_dispatch:
    types: [my-custom-event]

jobs:
  process-event:
    runs-on: ubuntu-latest
    steps:
      - name: Log event payload
        run: |
          echo "Event type: ${{ github.event.action }}"
          echo "Payload: ${{ toJSON(github.event.client_payload) }}"

Comprendre la configuration du récepteur

Dans l'exemple précédent :

on: repository_dispatch: indique à GitHub d'écouter cet événement.
types: [my-custom-event] précise que ce flux de travail ne s'exécutera que si l'événement envoyé est de type my-custom-event. Vous pouvez définir plusieurs types.
github.event.action contiendra le type d'événement (par exemple, my-custom-event).
github.event.client_payload contient les données personnalisées envoyées avec la notification.

Déclencher l’événement : envoyer depuis un autre dépôt

Pour déclencher un événement repository_dispatch, vous devez envoyer une requête HTTP POST à l’API GitHub. Vous pouvez le faire avec curl ou l’interface CLI de GitHub (gh cli) depuis un autre flux de travail GitHub Actions ou un script.

Exigences principales :

Le propriétaire et le nom du dépôt cible.
Un type d’événement que le flux de travail récepteur écoute.
Un client_payload pour transmettre des données personnalisées.
Un jeton d’accès personnel GitHub (PAT) avec la portée repo.

Exemple : distribuer un événement avec `gh cli`

Voici un flux de travail dans repo-A qui distribue un événement à repo-B. Remarquez que nous utilisons un secret pour le jeton et que nous transmettons un client_payload.

name: Trigger Deploy Workflow

on:
  push:
    branches: [main]

jobs:
  dispatch:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Install GitHub CLI
        run: sudo apt-get update && sudo apt-get install gh -y

      - name: Dispatch event to repo-B
        env:
          GH_TOKEN: ${{ secrets.CROSS_REPO_PAT }}
        run: |
          gh api \
            --method POST \
            -H "Accept: application/vnd.github.v3+json" \
            /repos/YOUR_ORG/repo-B/dispatches \
            -f event_type='my-custom-event' \
            -f client_payload='{"ref":"${{ github.ref }}", "sha":"${{ github.sha }}"}'

Sécuriser l’accès entre dépôts

Le GITHUB_TOKEN fourni par défaut à un flux de travail est limité au dépôt dans lequel ce flux s’exécute. Pour déclencher des événements dans *un autre* dépôt, vous avez besoin d’un jeton disposant d’autorisations plus larges.

Utilisez un jeton d’accès personnel (PAT) avec la portée repo.
Stockez ce PAT comme secret de dépôt (par exemple CROSS_REPO_PAT) dans le dépôt déclencheur.
Ne codez jamais directement des PAT en dur dans vos fichiers de flux de travail.

Transmettre des données personnalisées avec `client_payload`

Le client_payload est un objet JSON que vous pouvez inclure lors de la distribution d’un événement. Il est essentiel pour transmettre le contexte ou les données du flux de travail déclencheur au flux de travail récepteur.

Exemples de données que vous pouvez transmettre :

Le SHA du commit ou le nom de la branche à l’origine de la compilation.
Une cible d’environnement (par exemple, "staging", "production").
Un numéro de version d’un artefact à déployer.

N’oubliez pas : le client_payload est visible dans les journaux du flux de travail ; évitez donc d’y placer des informations sensibles.

Vérification rapide des flux de travail entre dépôts

Vous avez appris à orchestrer des flux de travail entre différents dépôts GitHub. Vérifions votre compréhension des composants principaux.

Récapitulatif : orchestrer des flux entre dépôts

Vous avez appris avec succès à mettre en œuvre des flux de travail entre dépôts à l’aide de repository_dispatch !

Pourquoi : pour gérer les dépendances et orchestrer des déploiements complexes entre plusieurs dépôts.
Comment : un flux de travail « émetteur » effectue un appel d’API à GitHub, ce qui déclenche un flux de travail « récepteur » dans un autre dépôt.
Élément clé : le type d’événement repository_dispatch et les types correspondants dans le flux de travail récepteur.
Données : utilisez client_payload pour transmettre des informations non sensibles entre les flux de travail.
Sécurité : utilisez toujours un PAT avec la portée repo, stocké comme secret, pour accéder aux autres dépôts.

Cette fonctionnalité puissante permet de créer des chaînes CI/CD très flexibles et découplées.

Questions Fréquemment Posées

La leçon « Flux de travail entre dépôts » est-elle gratuite ?

Oui — le texte complet de « Flux de travail entre dépôts » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours CI/CD with GitHub Actions & DevOps Pipelines, passe à CoddyKit PRO. Le cours CI/CD with GitHub Actions & DevOps Pipelines comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Flux de travail entre dépôts » ?

Apprenez à enchaîner des flux de travail entre différents dépôts pour gérer les dépendances et orchestrer des déploiements complexes. Tu pratiques CI/CD with GitHub Actions & DevOps Pipelines avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer CI/CD with GitHub Actions & DevOps Pipelines ?

Aucune expérience préalable n'est requise. CI/CD with GitHub Actions & DevOps Pipelines sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.

Combien de temps prend la leçon « Flux de travail entre dépôts » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon CI/CD with GitHub Actions & DevOps Pipelines ?

Oui. Chaque leçon CI/CD with GitHub Actions & DevOps Pipelines inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

Intégration et livraison continues pour les monodépôts
Flux de travail entre dépôts
Gestion centralisée des flux de travail
Filtrage des chemins et compilations sélectives

← Retour à CI/CD with GitHub Actions & DevOps Pipelines