Maximize Page
Tech & DevOps HubEspace Tech & DevOps: Explorez le monde du Dev, du Cloud et des outils DevOps à travers nos articles et discussions Explore the world of development, the cloud and DevOps tools

Automatisation des PR (promotions de branches)

Date de l'article:04-01-2026
CI/CD Github-Actions
Mise en place de workflows GitHub Actions pour automatiser la promotion de code entre branches (develop → staging → main) via des PR auto-créées. Couvre les stratégies envisagées, l'implémentation, les permissions requises et l'auto-merge
Concept: Promotion de branche en CI/CD

La promotion de branche CI/CD avec GitHub Actions automatise le passage de code entre environnements en déclenchant des workflows basés sur des événements Git. Elle permet de valider le code, construire des artefacts et déployer de manière sécurisée.


Le contexte

Actuellement, le flux est le suivant :
Feature → PR vers develop → merge après validation
Puis develop → staging → main, avec validation CI à chaque étape.

Ce processus étant chronophage, nous allons l'automatiser avec les conditions suivantes :
→ Déclenchement après push sur develop
→ Création automatique d'une PR vers staging (idem staging → main)

Contraintes à respecter suivant ma strategie gitflow:
→ Aucun push direct
→ Respect strict des protections de branches
→ Déclenchement uniquement après merge pour éviter les doubles exécutions CI
Flux:
feature branch
   ↓
PR → develop
   ↓ (CI OK)
merge

develop mis à jour
   ↓
PR → staging
   ↓ (CI OK)
merge

staging mis à jour
   ↓
PR → main
   ↓ (CI + tests OK)
merge manuel

Stratégies envisagées

Pour automatiser le passage entre branches, plusieurs approches sont possible, voyons cela rapidement:

Option 1 — Action create-pull-request (peter-evans)
Inadaptée dans mon cas:
  • Effectue des push (interdit dans ma stratégie)
  • Elle modifie directement les branches
  • Contourne partiellement les règles de protection
Option 2 — Utilisation de la CLI GitHub
Avantages:
  • Appel direct à l'API GitHub
  • Aucun push, donc respect des Branch Protection Rules
  • Offre un contrôle total sur la logique
Ce qu'il faut savoir

Les PR créées avec le GITHUB_TOKEN, par défaut ne déclenchent pas les workflows
     Il s'agit d'un mécanisme de sécurité pour éviter les boucles infinies.

Deux solutions posssibles:
  1. Accepter que la PR-auto n'ait pas accès à la CI et ne déclencher la CI qu'après le merge
  2. Utiliser un Personal Access Token (PAT). Dans ce cas, les events peuvent déclencher des workflows

Implémentation des Workflows

Pour définir les étapes, une pratique courante consiste à utiliser des fichiers YAML depuis .github/workflows/
Nous créons deux fichiers séparés, ce qui permet l'isolation des responsabilités et l'ajout d'extensions futures

Le fichier pr-develop-to-staging.yml
name: Auto PR - Develop to Staging

on:
  push:
    branches: [develop]

permissions:
  contents: read
  pull-requests: write
  actions: read

jobs:
  create-pr:
    runs-on: ubuntu-24.04

    steps:
      - name: Checkout code
        uses: actions/checkout@v6.0.2
        with:
          fetch-depth: 0

      - name: Create PR if needed
        env:
          GH_TOKEN: ${{ secrets.GH_PAT }}
        run: |
          set -e
          COMMITS=$(gh api \
            repos/${{ github.repository }}/compare/staging...develop \
            --jq '.ahead_by')

          if [ "$COMMITS" -eq 0 ]; then
            echo "No differences between develop and staging"
            exit 0
          fi

          COMMIT_MSG=$(git log -1 --pretty=%B)

          PR_NUMBER=$(gh pr list \
            --base staging \
            --head develop \
            --json number \
            --jq '.[0].number')

          if [ -z "$PR_NUMBER" ]; then
            gh pr create \
              --base staging \
              --head develop \
              --title "Promote develop → staging" \
              --body "Automatic promotion after successful CI.
Commit:
$GITHUB_SHA
https://github.com/${{ github.repository }}/commit/$GITHUB_SHA

Message:
$COMMIT_MSG" \
              --label "automated" \
              --label "promote"

            PR_NUMBER=$(gh pr list \
              --base staging \
              --head develop \
              --json number \
              --jq '.[0].number')
          else
            echo "PR already exists"
          fi

          echo "PR number: $PR_NUMBER"
          echo "$GITHUB_SHA" > deployed_version.txt

      - name: Upload deployment info
        uses: actions/upload-artifact@v7
        with:
          name: deployed-version
          path: deployed_version.txt


Le fichier "pr-staging-to-main" est similaire, vous pouvez le trouver dans le repository


Le workflow en bref
  • Est déclenché sur push vers develop
  • Compare develop → staging
  • Crée une PR si nécessaire
  • Ajoute des infos de traçabilité
  • Génère un artifact

Explications techniques
Comparaison
L'utilisation de ahead_by montre le nombre de commits en avance de develop sur staging.
Cela permet d'éviter les faux positifs
Fiabilité
set -e: Arrête le script si une commande échoue.
Ce qui sécurise le workflow
Gestion des PR
Création uniquement si absente (idempotence)
Informations disponibles
  • SHA du commit
  • Lien GitHub direct
  • Message du commit
ce qui permet l'audit et le debugging

Artifact de déploiement
Name Size
deployed-version.txt 194 Bytes
Le Digest contient le SHA déployé
→ Offre une traçabilité complète
→ Est utilisable dans d'autres jobs
→ Facilite le rollback

L'auto-merge n'est pas présent dans ce workflow de base. Il est ajouté dans la section suivante


Résultat
→   PR créée automatiquement
→   Contenu enrichi (commit + lien)
→   Artifact disponible dans GitHub Actions
→   Workflow robuste et traçable

Tester, une fois le code poussé:

Pour tester, les commits doivent diverger:

git checkout -b feature/pr-auto
echo "// test" >> README.md
git commit -am "trigger auto promotion"
git push origin feature/pr-auto
PR auto
Vue depuis les Actions
 Merge pull request #184 from val7304/staging-to-main 
    Prod Build, Analyze and Deploy Flashcards App #102: Commit f505634 pushed by val7304                      main 	    Feb 23, 1:43 AM GMT+1  4m 30s

 Promote staging → main
    Prod Build, Analyze and Deploy Flashcards App #101: Pull request #184 synchronize by val7304             staging 	    Feb 23, 1:37 AM GMT+1  4m 23s
	 
 Merge pull request #186 from val7304/develop-to-staging
    CI - Staging #155: Commit f7134b7 pushed by val7304                                                      staging 	    Feb 23, 1:37 AM GMT+1  7m 22s

 Promote develop → staging
   CI - Staging #154: Pull request #186 synchronize by val7304                                               develop 	    Feb 23, 1:32 AM GMT+1  4m 26s

 Merge pull request #176 from val7304/develop
   CI - Staging #149: Commit c94e694 pushed by val7304                                                      staging   	   Feb 22, 10:49 PM GMT+1  7m 12s

 Merge pull request #175 from val7304/feature/pr-auto
   CI - Develop #109: Commit 0648c2f pushed by val7304                                                      develop   	   Feb 22, 10:40 PM GMT+1  2m 24s

Bonus: Auto-merge

Ajout de l'auto-merge pour finaliser automatiquement la PR après validation des checks.

Modification du workflow, ajout en fin de script
gh pr merge "$PR_NUMBER" \
  --auto \
  --merge

Cette commande active l'auto-merge et attend que tous les required checks soient validés

Flux final
feature → develop
↓
PR auto
↓
CI OK
↓
merge auto

Configuration GitHub
Conditions obligatoires
Branch protection activée
Required checks configurés
Token avec permission pull_request: write

Option Allow auto-merge activée :
  Sinon GitHub n'activera pas l'auto-merge correctement

Voir les règles de protection des branches pour rappel

Ce qui NE doit PAS être activé
Require approval
Si activé, le merge restera bloqué sans validation humaine

Si la branche cible (staging) exige:
reviews obligatoires
checks obligatoires
→ l'auto-merge attendra leur validation

Modifier les permissions et activer l'auto-merge

1. Modifier les permissions du token PAT: Contents: read and write

developer settings change permission content

2. Configuration Github

Depuis le projet Settings, activer:

You can allow setting pull requests to merge automatically once all required reviews and status checks have passed

 Allow auto-merge 
Waits for merge requirements to be met and then merges automatically. 
Résultat :
PR créée automatiquement
CI exécutée sur staging
Merge automatique si tous les checks sont valides
L'auto-merge ne déclenche pas la CI. Il attend uniquement que les checks configurés soient validés
Même si nous avons configuré l'auto-merge, l'option manuelle durant la phase où le PR tourne reste disponible via le menu-liste de merge

Résultat global

→ La Promotion est automatisée, la validation CI est exécutée à chaque étape.
→ Le merge automatique est contrôlé. Le pipeline est fiable et traçable

Feature / Develop
PR #200
feature/add-auto-merge-dev-staging → develop
CI - Develop #131
Merge effectué
PR #201
fix json flag
CI - Develop #133 / #134
Merge effectué
Auto PR #202 vers Staging
Staging
PR #202
develop → staging
CI - Staging #160 / #161
Merge effectué
Auto PR #203 vers Main
Main (Production)
PR #203
staging → main
CI Production #107
Merge manuel
Deploy exécuté (#108)

Point important
     Le repository reste la source de vérité en cas de divergence liée aux mises à jour CI/CD.
Dans l'article suivant, je conclus brièvement et j'introduit plusieurs tableaux de suivis et de mises à jours pour ce projet "Flashcards avec sa CI/CD Github Actions"

Laissez-moi un commentaire

En postant un commentaire anonyme, vous adhérez automatiquement aux conditions d'utilisation du site.