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: true
    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@v5
      with:
        push: true
        tags: ${{ inputs.image }}:${{ inputs.tag }}

inputs déclare les paramètres d'entrée. outputs expose des valeurs vers le workflow appelant. runs.using: "composite" indique qu'il s'agit d'une séquence de steps YAML.

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. Pour une organisation, le dépôt peut être privé à condition de l'autoriser dans les paramètres de l'organisation (Settings → Actions → General → Access).

Sécurité

Toujours épingler une version explicite (@v2, @abc1234) plutôt que @main. Une action externe modifiée peut injecter du code malveillant dans tous les workflows qui en dépendent. Le hash de commit est l'option la plus sûre : 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.