GitHub Actions : action réutilisable

Quand une séquence de steps se répète dans plusieurs workflows (checkout + setup + build, ou authentification + push Docker), la factoriser dans une action évite la duplication et centralise la maintenance. Une correction ou une mise à jour s'applique à tous les workflows consommateurs sans toucher chacun individuellement.

Types d'actions

GitHub Actions propose trois types d'actions :

Type	Mécanisme	Usage
Composite	Séquence de steps YAML	Factoriser des steps existantes
JavaScript	Node.js	Logique complexe, accès à l'API GitHub
Docker	Conteneur Docker	Environnement d'exécution spécifique

Les actions composites couvrent la majorité des besoins sans nécessiter de code JavaScript ni de Dockerfile.

Créer une action composite

Une action se définit dans un fichier action.yml placé dans le dépôt. Le chemin est libre : .github/actions/deploy/action.yml est une convention courante pour les actions locales.

# .github/actions/docker-build-push/action.yml
name: "Docker Build and Push"
description: "Build a Docker image and push it to a registry"

inputs:
  image:
    description: "Image name (e.g. ghcr.io/org/app)"
    required: true
  tag:
    description: "Image tag"
    required: false
    default: "latest"
  registry-token:
    description: "Registry authentication token"
    required: true

outputs:
  digest:
    description: "Image digest"
    value: ${{ steps.push.outputs.digest }}

runs:
  using: "composite"
  steps:
    - name: Log in to registry
      uses: docker/login-action@v3
      with:
        registry: ghcr.io
        username: ${{ github.actor }}
        password: ${{ inputs.registry-token }}

    - name: Build and push
      id: push
      uses: docker/build-push-action@v6
      with:
        push: true
        tags: ${{ inputs.image }}:${{ inputs.tag }}

    - name: Print digest
      shell: bash
      run: echo "Pushed ${{ inputs.image }}@${{ steps.push.outputs.digest }}"

inputs déclare les paramètres d'entrée. outputs expose des valeurs vers le workflow appelant ; dans une action composite, chaque sortie doit être rattachée explicitement à la sortie d'une step via value. runs.using: "composite" indique qu'il s'agit d'une séquence de steps YAML.

Plusieurs contraintes distinguent une step d'action composite d'une step de workflow :

• une step run doit déclarer son shell (bash, pwsh, python...), sans valeur par défaut ;
• le contexte secrets n'est pas accessible : un secret doit être transmis explicitement comme input, comme registry-token ci-dessus ;
• les entrées sont lues via ${{ inputs.<nom> }} ; elles ne sont pas exposées automatiquement comme variables d'environnement INPUT_<NOM>, contrairement aux actions JavaScript et Docker.

Utiliser l'action dans un workflow

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build and push API image
        uses: ./.github/actions/docker-build-push
        with:
          image: ghcr.io/${{ github.repository }}/api
          tag: ${{ github.sha }}
          registry-token: ${{ secrets.GITHUB_TOKEN }}

uses: ./.github/actions/docker-build-push référence une action locale au dépôt. Pour référencer une action dans un autre dépôt :

      - uses: org/shared-actions/.github/actions/docker-build-push@v2
        with:
          image: ghcr.io/org/app
          tag: latest
          registry-token: ${{ secrets.GITHUB_TOKEN }}

Partager des actions entre dépôts

Une action définie dans un dépôt public est accessible depuis n'importe quel workflow. Une action hébergée dans un dépôt privé ou interne n'est utilisable par les autres dépôts du même propriétaire (utilisateur ou organisation) qu'après autorisation explicite dans les paramètres du dépôt qui la contient (Settings → Actions → General → Access).

Sécurité

Toujours épingler une version explicite (@v2 ou un SHA de commit) plutôt que @main. Une action externe modifiée peut injecter du code malveillant dans tous les workflows qui en dépendent. Un tag peut être déplacé ; seul le SHA complet (40 caractères, les SHA abrégés ne sont pas acceptés) est immuable : uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683.

Différence entre action et workflow réutilisable

	Action composite	Workflow réutilisable
Déclaration	action.yml	.github/workflows/*.yml
Appel	uses dans une step	uses dans un job (workflow_call)
Environnement	Hérite du job appelant	Définit son propre runner
Outputs	Via outputs	Via jobs.<job>.outputs

Un workflow réutilisable convient pour encapsuler un pipeline complet (build + test + push) qui s'exécute dans son propre environnement. Une action composite convient pour factoriser une séquence de steps qui s'exécute dans le contexte du job appelant. L'article architecture CI/CD réutilisable combine les deux mécanismes à l'échelle de plusieurs dépôts.