Gitea Actions : déclencheurs, jobs et conditions

Déclencheurs

on:
  push:
    branches: [main, 'release/**']
    tags: ['v*']
    paths:
      - 'src/**'
      - 'package.json'
    paths-ignore:
      - '**.md'
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 3 * * 1'
  workflow_dispatch:
  release:
    types: [published]

Événement	Quand
push	Poussée de commits ou de tags
pull_request	Ouverture, mise à jour d’une demande de fusion
schedule	Planification cron (UTC)
workflow_dispatch	Lancement manuel depuis l’interface
release	Publication d’une version
workflow_call	Workflow appelé par un autre (selon la version)

Remarques :

• branches et tags acceptent des motifs (*, **).
• paths limite l’exécution aux commits qui modifient certains fichiers (économise du temps de calcul).
• Les expressions cron s’évaluent en UTC et ne s’exécutent que si un runner est disponible.
• workflow_dispatch ajoute un bouton « Exécuter le workflow » dans l’onglet Actions.

Lancement manuel avec paramètres

on:
  workflow_dispatch:
    inputs:
      environnement:
        description: 'Cible du déploiement'
        required: true
        default: 'staging'
        type: choice
        options: [staging, production]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Déploiement vers ${{ inputs.environnement }}"

Éviter l’exécution : [skip ci]

Un commit dont le message contient [skip ci] (ou [ci skip], [no ci], [skip actions]) ne déclenche pas les workflows :

git commit -m "docs: corriger une faute [skip ci]"

Plusieurs jobs et dépendances

Les jobs s’exécutent en parallèle par défaut. needs impose un ordre :

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run lint

  tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

  build:
    needs: [lint, tests] # attend la réussite des deux
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build

Les jobs ne partagent pas de fichiers : pour transmettre un résultat (dossier dist/), utiliser un artefact (voir Cache et artefacts). Une sortie simple se transmet avec outputs :

jobs:
  version:
    runs-on: ubuntu-latest
    outputs:
      numero: ${{ steps.v.outputs.numero }}
    steps:
      - id: v
        run: echo "numero=1.2.3" >> "$GITHUB_OUTPUT"
  suite:
    needs: version
    runs-on: ubuntu-latest
    steps:
      - run: echo "Version ${{ needs.version.outputs.numero }}"

Matrices

Répéter un job avec plusieurs combinaisons :

jobs:
  tests:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        node: [20, 22, 24]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
      - run: npm ci && npm test

Option	Effet
fail-fast: false	Poursuit les autres combinaisons si l’une échoue
max-parallel	Limite le nombre d’exécutions simultanées
include / exclude	Ajoute ou retire des combinaisons

Chaque combinaison consomme un runner : une grande matrice sur un seul runner s’exécute en file d’attente.

Conditions

steps:
  - run: ./deployer.sh
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'

  - run: echo "Branche de fonctionnalité"
    if: startsWith(github.ref, 'refs/heads/feature/')

  - run: ./nettoyer.sh
    if: always() # même après un échec

  - run: ./notifier-echec.sh
    if: failure()

Fonction	Vrai quand
success()	Étapes précédentes réussies (défaut)
failure()	Une étape précédente a échoué
always()	Toujours
cancelled()	Exécution annulée

Un job aussi peut avoir if :

jobs:
  deploy:
    if: gitea.ref == 'refs/heads/main'
    needs: [tests]
    runs-on: ubuntu-latest
    steps:
      - run: echo "déploiement"

Concurrence

Éviter plusieurs exécutions simultanées d’un même déploiement :

concurrency:
  group: deploiement-${{ gitea.ref }}
  cancel-in-progress: true

La prise en charge de concurrency dépend de la version de Gitea : vérifier dans la documentation de la version utilisée, et sinon limiter le nombre de runners ou verrouiller dans le script de déploiement.

Filtrer sur les demandes de fusion

on:
  pull_request:
    types: [opened, synchronize, reopened]
    paths: ['src/**']

Les workflows déclenchés par une demande de fusion issue d’un fork ne reçoivent pas les secrets du dépôt de destination.

Dépannage

Symptôme	Piste
Le workflow ne se déclenche pas	Filtre branches / paths, [skip ci], Actions désactivé dans le dépôt
Déclenché deux fois	push et pull_request sur la même branche : filtrer (push: branches: [main])
schedule ne démarre pas	Fuseau UTC, runner indisponible, workflow absent de la branche par défaut
Un job n’attend pas l’autre	needs manquant
if toujours faux	Mauvais contexte : afficher echo "${{ gitea.ref }}"
Fichiers absents dans le second job	Jobs sur des conteneurs distincts : utiliser un artefact

Ubuntu 24.04 et 26.04 : différences à connaître

Aucune : ces fonctions dépendent de Gitea et du runner, pas d’Ubuntu.

Pour aller plus loin

• Syntaxe des workflows
• Suite : Secrets et variables

Dans la même rubrique

• Présentation et activation
• Écrire un workflow
• Déclencheurs, jobs et conditions
• Secrets et variables
• Cache et artefacts
• Exemples de workflows
• Dépannage