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 de la promotion de branches 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
develop → staging → main, lancement manuel des PR, avec validation CI à chaque étape

Contraintes à respecter suivant ma strategie git flow:
→ Aucun push direct
→ Respect strict des protections de branches
→ Déclenchement uniquement après merge pour éviter les doubles exécutions CI

Ce processus étant chronophage, nous allons l'automatiser avec les conditions suivantes :
→ Déclenchement après push sur develop, activer l'auto-merge
→ Création automatique d'une PR vers staging (idem staging → main)
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

Configuration Github
1. Créer le PAT
1. Créer le token: Cliquer sur votre profil: dans le menu, choisir settings
Aller en bas de page: Cliquez sur Developer Settings
Cliquez sur "Personal access tokens" et choisir "Fine-grained tokens"
2. Donner un nom au token: GH_PAT
Le token commence par github_pat_****
3. Donnez lui les permissions:
→ Le limiter au repository concerné en le choissant dans la liste de vos projets
→ Contents: Read (sans auto merge) & Write (pour l'auto-merge)
→ Pull requests: Read & Write
→ Metadata: Read

2. Ajouter le PAT au secrets
Pour que le workflow puisse l'utiliser, il faut donc l'ajouter au secret Github:
Settings → Secrets and variables → Actions → New repository secret
Name: GH_PAT
Value: token_value	

3. Créer les labels
Dans le workflow nous appellerons des labels qui serviront à déclencher le workflows en fonction de celui-ci défini
Depuis le projet , onglet Pull Request, Cliquez sur Labels 14

Créez-les en cliquant sur le sur bouton

automated: Indique que cette PR a été créée par script
promote: Indique l'intention de la PR, une montée en version (promotion) vers l'environnement de staging

Implémentation des 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" (Version de base)
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

          AHEAD=$(gh api \
            repos/${{ github.repository }}/compare/staging...develop \
            --jq '.ahead_by')
            
          if [ "$AHEAD" -eq 0 ]; then
            echo "No differences between develop and staging"
            exit 0
          fi

          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." \
              --label "automated" \
              --label "promote"
            
            PR_NUMBER=$(gh pr list \
              --base staging \
              --head develop \
              --json number \
              --jq '.[0].number')
          else
            echo "PR already exists: #$PR_NUMBER"
          fi
          echo "PR number: $PR_NUMBER"


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
  • Vérifie si une PR existe déjà
  • Crée la PR uniquement si nécessaire

Explications techniques
Fiabilité
set -e: Arrête le script si une commande échoue.
Ce qui sécurise le workflow
Comparaison
L'utilisation de ahead_by montre le nombre de commits en avance de develop sur staging.
Cela permet d'éviter les faux positifs
Gestion des PR
Création uniquement si absente (idempotence)
Informations disponibles
Le numéro de la Pull Request créée est récupéré automatiquement afin de pouvoir :
  • vérifier son existence
  • éviter les doublons
  • activer l'auto-merge si nécessaire

→ Évite les PR dupliquées
→ Respecte les règles de protection GitHub
→ Automatise la promotion entre environnements

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 si nécessaire
→ Aucun doublon grâce à la vérification préalable
→ Respect des protections de branches GitHub
→ Workflow idempotent et robuste

Tester, une fois le code poussé:

Pour tester, les commits doivent diverger:

git switch -C feature/pr-auto
echo "// test" >> README.md
git commit -am "trigger auto promotion"
git push origin feature/pr-auto

PR auto
Techniquement: la commande "git push" ne déclenche rien ; C'est le merge de la PR feature, vers develop, qui déclenche un push sur developqui, à son tour, lors du push, lancera le workflow "PR-auto"
Pour tester le mécanisme complet, et suivant ma stratégie Gitlow, la procédure est de créer une branche feature, ouvrir une Pull Request vers develop puis la fusionner. Le push résultant sur develop déclenchera automatiquement la promotion vers staging.
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 : activation de l'auto-merge (only develop → staging)
On ajoute l'auto-merge pour finaliser automatiquement la PR entre develop → staging, après validation des checks
Modification du workflow, ajouter en fin de script:
gh pr merge "$PR_NUMBER" \
  --auto \
  --merge
Cette commande active le mode "auto-merge" et attend que tous les "required checks" de la CI, soient validés
Flux final
  feature → develop
      ↓
    PR auto
      ↓
    CI OK
      ↓
  merge auto
Dans l'UI GitHub, durant tout le déroulé du PR on voit bien:
La PR en état "Auto-merge enabled", et les options GitHub habituelles restent disponibles:
  • Create a merge commit: conserve tout l'historique des commits avec un commit de fusion.
  • Squash and merge: regroupe tous les commits de la PR en un seul commit.
  • Rebase and merge: rejoue les commits de la PR proprement sans commit de merge.
  • Disable auto-merge désactive la fusion automatique de la PR.
Ces options restent disponibles durant toutes les phases de vérifications de la PR, on peux donc encore modifier le mode.

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)

En résumé

develop → staging:auto-merge → permet une intégration rapide et continue des features dans l'environnement de validation sans intervention humaine systématique.

staging → main: garde une validation manuelle qui ajoute un contrôle final avant production pour s'assurer de la stabilité, conformité métier, sécurité et éviter qu'un incident atteigne l'environnement live


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, nous verrons comment améliorer le Dockerfile, nous parlerons aussi du Dockerfile.debug et ce qu'il peux nous apporter.
      Enfin nous verrons comment Actuator peux nous aider encore + à diagnostiquer les problèmes (à défaut de ne pouvoir entrer dans le container)
Naviguez entre les articlesBrowse through the articles

Laissez-moi un commentaire

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