Gitea Actions : exemples de workflows

Modèles à adapter. Les noms (monapp, exemple.com) sont fictifs. Pour les secrets utilisés, voir Secrets et variables.

Site Node.js : vérification et build

.gitea/workflows/ci.yaml :

name: CI
on:
  push:
    branches: [main]
  pull_request:

jobs:
  verifier:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

Avec pnpm, installer pnpm avant setup-node (npm install -g pnpm), puis pnpm install --frozen-lockfile (voir Node.js : pnpm et Yarn).

Python : ruff et pytest

name: Python
on: [push, pull_request]

jobs:
  tests:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        python: ['3.12', '3.13']
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python }}
          cache: pip
      - run: pip install -r requirements.txt pytest ruff
      - run: ruff check .
      - run: pytest -q

Voir Python : qualité et tests.

PHP : Composer et tests

name: PHP
on: [push, pull_request]

jobs:
  tests:
    runs-on: ubuntu-latest
    container:
      image: php:8.3-cli
    steps:
      - uses: actions/checkout@v4
      - run: |
          apt-get update && apt-get install -y --no-install-recommends unzip git
          php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
          php composer-setup.php --install-dir=/usr/local/bin --filename=composer
          composer install --no-interaction --prefer-dist
          vendor/bin/phpunit

Vérifier l’empreinte du script d’installation de Composer comme l’indique getcomposer.org, ou utiliser une image qui contient déjà Composer.

Construire une image Docker

name: Image
on:
  push:
    tags: ['v*']

jobs:
  image:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Connexion au registre
        run: echo "${{ secrets.REGISTRY_TOKEN }}" | docker login git.exemple.com -u "${{ gitea.actor }}" --password-stdin
      - name: Construire et publier
        run: |
          image="git.exemple.com/${{ gitea.repository }}"
          docker build -t "$image:${{ gitea.ref_name }}" -t "$image:latest" .
          docker push "$image:${{ gitea.ref_name }}"
          docker push "$image:latest"

Ce job a besoin de l’accès à Docker : monter le socket Docker dans les conteneurs du runner ou utiliser un runner dédié (voir l’avertissement de Présentation sur la sécurité). Le registre de paquets de Gitea accepte un jeton d’accès avec le droit write:package stocké en secret.

Déploiement par rsync et SSH

name: Déploiement
on:
  push:
    branches: [main]

jobs:
  deployer:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci && npm run build

      - name: Préparer SSH
        run: |
          apt-get update && apt-get install -y --no-install-recommends openssh-client rsync
          install -m 700 -d ~/.ssh
          printf '%s\n' "${{ secrets.DEPLOY_KEY }}" > ~/.ssh/id_ed25519
          chmod 600 ~/.ssh/id_ed25519
          printf '%s\n' "${{ vars.DEPLOY_KNOWN_HOSTS }}" > ~/.ssh/known_hosts

      - name: Synchroniser
        run: |
          rsync -az --delete -e "ssh -p ${{ vars.DEPLOY_PORT }}" dist/ \
            "${{ vars.DEPLOY_USER }}@${{ vars.DEPLOY_HOST }}:${{ vars.DEPLOY_PATH }}/"

rsync --delete supprime du serveur ce qui n’est plus dans dist/ : tester d’abord avec --dry-run, et protéger le dossier cible. Ne déclencher le déploiement que sur la branche principale.

Publier une version

name: Version
on:
  push:
    tags: ['v*']

jobs:
  version:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build && tar -czf site.tar.gz dist
      - name: Créer la version et joindre l'archive
        run: |
          api="${{ gitea.server_url }}/api/v1/repos/${{ gitea.repository }}"
          id=$(curl -s -X POST "$api/releases" \
            -H "Authorization: token ${{ secrets.RELEASE_TOKEN }}" \
            -H "Content-Type: application/json" \
            -d "{\"tag_name\":\"${{ gitea.ref_name }}\",\"name\":\"${{ gitea.ref_name }}\"}" | python3 -c 'import json,sys; print(json.load(sys.stdin)["id"])')
          curl -s -X POST "$api/releases/$id/assets?name=site.tar.gz" \
            -H "Authorization: token ${{ secrets.RELEASE_TOKEN }}" \
            -F "attachment=@site.tar.gz"

Le jeton RELEASE_TOKEN est un jeton d’accès personnel avec le droit d’écriture sur le dépôt.

Notification d’échec

- name: Prévenir en cas d'échec
  if: failure()
  run: |
    curl -s -X POST "${{ secrets.WEBHOOK_URL }}" \
      -H "Content-Type: application/json" \
      -d "{\"texte\":\"Échec : ${{ gitea.repository }} (${{ gitea.ref_name }})\"}"

Reproduire en local

Les commandes d’un workflow doivent pouvoir s’exécuter sans Gitea : les placer dans un script du dépôt (scripts/ci.sh) et l’appeler depuis le workflow. Pour tester le workflow lui-même sur son poste, l’outil act exécute des workflows compatibles dans Docker (act -l, act push).

Dépannage

Symptôme	Piste
`docker: command not found` dans un job	Docker absent du conteneur : image avec le client Docker et socket monté dans le runner
`apt-get: Permission denied`	Utilisateur non-root dans l’image : utiliser une image qui s’exécute en root ou `sudo`
`rsync: command not found`	L’installer dans le workflow (voir l’exemple)
Le déploiement part sur une branche de test	Ajouter `branches: [main]`
`curl` renvoie 401	Jeton absent, expiré ou sans le bon droit
Image Docker non publiée	Connexion au registre : adresse, utilisateur et droit `write:package`

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

Les exemples sont indépendants de l’hôte. Pour que les jobs utilisent Ubuntu 24.04 ou 26.04, associer l’étiquette du runner à l’image correspondante (ubuntu:24.04, ubuntu:26.04).

Pour aller plus loin

Exemples de workflows
Suite : Dépannage