Gitea Actions : secrets et variables

Secrets et variables

	Secret	Variable
Contenu	Valeur confidentielle (mot de passe, clé, jeton)	Valeur non confidentielle (adresse, nom, option)
Affichage	Jamais relu dans l’interface ; masqué dans les journaux	Lisible
Utilisation	${{ secrets.NOM }}	${{ vars.NOM }}

Où les définir

Portée	Emplacement
Dépôt	Paramètres du dépôt > Actions > Secrets (ou Variables)
Organisation	Paramètres de l’organisation > Actions > Secrets
Utilisateur	Paramètres de l’utilisateur > Actions > Secrets

Un secret de portée plus étroite remplace celui de portée plus large du même nom. Les noms sont en majuscules (DEPLOY_KEY) et ne peuvent pas commencer par GITEA_ ni GITHUB_.

Utiliser dans un workflow

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      SITE_URL: ${{ vars.SITE_URL }}
    steps:
      - uses: actions/checkout@v4
      - run: ./deployer.sh
        env:
          DEPLOY_HOST: ${{ vars.DEPLOY_HOST }}
          API_TOKEN: ${{ secrets.API_TOKEN }}

Passer un secret par une variable d’environnement (env:) et non en l’écrivant dans la ligne de commande : les arguments peuvent apparaître dans les journaux d’erreur ou la liste des processus.

Attention

Ne jamais afficher un secret (echo "$API_TOKEN", set -x avec un secret dans la commande). Gitea masque les valeurs exactes dans les journaux, mais une valeur transformée (encodée, découpée) n’est plus reconnue. Un secret mal protégé se révoque et se remplace : modifier la valeur dans l’interface ne suffit pas, il faut aussi la changer chez le service concerné.

Le jeton intégré

steps:
  - uses: actions/checkout@v4
  - run: |
      curl -s -H "Authorization: token ${{ gitea.token }}" \
        "${{ gitea.server_url }}/api/v1/repos/${{ gitea.repository }}/issues?limit=5"

gitea.token (équivalent de github.token) est un jeton temporaire, valable pour la durée du job, avec les droits du dépôt courant. Pour agir sur un autre dépôt (publier un paquet, pousser ailleurs), créer un jeton d’accès personnel dédié avec le minimum de droits et le stocker en secret.

Clé SSH de déploiement

1. Générer une clé réservée au déploiement (voir SSH : clés) :

ssh-keygen -t ed25519 -f deploiement -N "" -C "gitea-actions-deploiement"

2. Ajouter la clé publique (deploiement.pub) dans ~/.ssh/authorized_keys de l’utilisateur de déploiement sur le serveur, de préférence avec des restrictions (restrict,command=... ou from="adresse-du-runner").
3. Stocker la clé privée (deploiement) dans un secret DEPLOY_KEY, puis supprimer le fichier local.
4. Enregistrer l’empreinte du serveur dans une variable DEPLOY_KNOWN_HOSTS (résultat de ssh-keyscan -p 22 serveur.exemple.com, vérifié à la main).

- name: Préparer SSH
  run: |
    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

Ne pas désactiver la vérification de la clé du serveur (StrictHostKeyChecking=no) : cela expose le déploiement à une usurpation.

Valeurs par défaut et fichiers .env

Ne pas versionner de .env contenant des secrets. Générer un fichier au besoin à partir des secrets, dans le job :

- run: |
    umask 077
    printf 'API_TOKEN=%s\n' "$API_TOKEN" > .env
  env:
    API_TOKEN: ${{ secrets.API_TOKEN }}

Bonnes pratiques

• Un secret par usage, avec des droits minimaux ; pas de clé personnelle de l’administrateur.
• Rotation régulière, et révocation immédiate en cas de doute.
• Secrets de portée organisation seulement s’ils sont réellement partagés.
• Ne pas exposer les secrets aux workflows de demandes de fusion issues de forks (Gitea ne les transmet pas).
• Restreindre qui peut modifier .gitea/workflows/ : un workflow modifié peut lire les secrets disponibles.

Dépannage

Symptôme	Piste
${{ secrets.NOM }} vide	Mauvaise portée ou nom incorrect ; workflow lancé par un fork
Secret affiché *** dans les journaux	Comportement normal (masquage)
Permission denied (publickey) au déploiement	Clé privée mal collée (saut de ligne final), clé publique absente du serveur, droits du fichier
Host key verification failed	known_hosts absent ou obsolète
403 avec gitea.token sur un autre dépôt	Le jeton intégré est limité au dépôt courant : jeton dédié
Variable non modifiée	Variables lues au lancement : relancer l’exécution

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

Aucune sur la gestion des secrets. Pour SSH : OpenSSH 10 (26.04) retire certains algorithmes anciens ; une clé ed25519 fonctionne sur les deux versions (voir SSH : installation).

Pour aller plus loin

• Secrets Gitea Actions
• Suite : Cache et artefacts

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