Secrets et variables
Pourquoi ne jamais mettre des credentials en clair
Un workflow GitHub Actions est un fichier YAML versionné dans ton dépôt. Si tu y écris un mot de passe, une clé API ou un token, cette information devient visible par tout le monde — et surtout, elle reste dans tout l'historique Git même après suppression.
Ne jamais écrire de credentials en clair dans un fichier YAML. Même dans un dépôt privé, des clés exposées peuvent être aspirées par des outils tiers, des forks ou des logs de CI. GitHub scanne automatiquement les dépôts pour détecter des secrets connus et te prévient — mais il vaut mieux ne jamais en arriver là.
Les secrets GitHub
GitHub propose un coffre-fort chiffré pour stocker tes informations sensibles : Settings > Secrets
and variables > Actions. Les secrets sont chiffrés au repos, masqués dans les logs (***)
et jamais exposés en clair, même aux mainteneurs du dépôt.
Pour créer un secret : dans ton dépôt, va dans
Settings > Secrets and variables > Actions > New repository secret.
Donne-lui un nom en majuscules avec underscores (ex. DEPLOY_KEY) et colle la valeur.
Une fois enregistré, la valeur n'est plus lisible — seulement modifiable ou supprimable.
Tu peux aussi créer des secrets au niveau de l'organisation (partagés entre plusieurs dépôts) ou des environnements (secrets différents selon staging/production). Les secrets d'environnement nécessitent une approbation manuelle optionnelle avant déploiement.
Utiliser un secret dans le YAML
On accède à un secret via la syntaxe ${{ secrets.NOM_DU_SECRET }}.
GitHub remplace cette expression par la valeur réelle au moment de l'exécution, sans jamais l'afficher.
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Déployer via SSH
env:
SSH_KEY: ${{ secrets.DEPLOY_SSH_KEY }}
API_TOKEN: ${{ secrets.API_TOKEN }}
run: |
echo "Connexion avec la clé SSH..."
./scripts/deploy.sh
Variables d'environnement avec env:
Les variables d'environnement non sensibles se déclarent avec le bloc env:.
On peut les définir à trois niveaux différents, du plus global au plus local :
- Niveau workflow — disponible dans tous les jobs et steps
- Niveau job — disponible dans tous les steps du job
- Niveau step — disponible uniquement dans ce step
name: CI
env: # niveau workflow — global
NODE_ENV: production
APP_NAME: monapp
jobs:
build:
runs-on: ubuntu-latest
env: # niveau job
BUILD_DIR: ./dist
steps:
- name: Build
env: # niveau step
VERBOSE: "true"
run: npm run build
Les variables contextuelles automatiques
GitHub expose automatiquement des informations sur le contexte d'exécution via des expressions
${{ ... }}. Les plus utiles :
steps:
- name: Afficher les infos du contexte
run: |
echo "Déclenché par : ${{ github.actor }}"
echo "Branche : ${{ github.ref }}"
echo "SHA du commit : ${{ github.sha }}"
echo "Dépôt : ${{ github.repository }}"
echo "Event : ${{ github.event_name }}"
${{ github.actor }}— nom de l'utilisateur qui a déclenché le workflow${{ github.sha }}— SHA complet du commit courant${{ github.ref }}— référence Git (ex.refs/heads/main)${{ github.repository }}— nom du dépôt (ex.user/monrepo)${{ github.event_name }}— type d'événement (push,pull_request…)${{ runner.os }}— système d'exploitation du runner
Variables d'environnement prédéfinies
En plus des expressions ${{ ... }}, le runner expose des variables d'environnement shell
classiques, accessibles directement dans les commandes run: :
$GITHUB_WORKSPACE— chemin absolu vers le répertoire où le code est cloné$GITHUB_SHA— SHA du commit (équivalent shell de${{ github.sha }})$GITHUB_REF— référence Git courante$GITHUB_REPOSITORY—owner/repo$RUNNER_OS—Linux,WindowsoumacOS$RUNNER_TEMP— répertoire temporaire du runner, nettoyé après chaque job
Préfère les expressions ${{ github.sha }} pour les valeurs interpolées dans le YAML
(steps conditionnels, noms d'artefacts…) et les variables $GITHUB_SHA dans les scripts shell
des blocs run:. Les deux pointent vers la même valeur.
Exemple concret : déploiement SSH avec clé privée
Voici un workflow complet qui utilise une clé SSH stockée en secret pour déployer sur un serveur distant. La clé privée ne doit jamais apparaître dans les fichiers ni dans les logs.
Pour que ce workflow fonctionne, tu dois : (1) stocker ta clé privée SSH dans un secret
DEPLOY_SSH_KEY, (2) ajouter la clé publique correspondante dans
~/.ssh/authorized_keys sur ton serveur, et (3) stocker l'adresse du serveur dans
un secret DEPLOY_HOST et l'utilisateur dans DEPLOY_USER.
name: Deploy to production
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout du code
uses: actions/checkout@v4
- name: Configurer la clé SSH
run: |
mkdir -p ~/.ssh
echo "${{ secrets.DEPLOY_SSH_KEY }}" > ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa
ssh-keyscan ${{ secrets.DEPLOY_HOST }} >> ~/.ssh/known_hosts
- name: Déployer sur le serveur
env:
HOST: ${{ secrets.DEPLOY_HOST }}
USER: ${{ secrets.DEPLOY_USER }}
COMMIT: ${{ github.sha }}
run: |
ssh $USER@$HOST "cd /var/www/monapp && git pull && npm ci && pm2 restart monapp"
echo "Déployé commit $COMMIT avec succès"
- Ne jamais écrire de credentials en clair dans le YAML — utilise Settings > Secrets and variables > Actions.
- Accès à un secret :
${{ secrets.NOM_SECRET }}— GitHub masque la valeur dans les logs. env:peut se placer au niveau workflow, job ou step — du plus global au plus local.- Variables contextuelles utiles :
${{ github.actor }},${{ github.sha }},${{ github.ref }}. - Variables shell prédéfinies :
$GITHUB_WORKSPACE,$RUNNER_OS,$GITHUB_SHA. - Pour un déploiement SSH : stocker la clé privée en secret, jamais dans le code.