# Publier sur WordPress.org depuis GitHub Actions sans toucher à SVN

> Une action de déploiement SVN, un .distignore soigné, et la gestion des assets et des tags : automatiser la publication d'une extension depuis Git.

- Auteur : Clément Hadrot
- Publié le : 2022-09-23
- Mis à jour le : 2022-09-23
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/publier-wordpress-org-github-actions-svn/

## L’essentiel

- Une action toute prête évite d'apprendre les commandes SVN
- .distignore pour exclure fichiers de dev et dépendances
- Tag automatique déclenché par une release GitHub

Le répertoire officiel des extensions WordPress fonctionne encore sur Subversion, un système de gestion de version que la majorité des développeurs actuels n'a jamais utilisé au quotidien — Git a pris toute la place depuis longtemps. Publier une mise à jour d'extension impliquait donc traditionnellement d'installer un client SVN, de cloner le dépôt du plugin, de copier les fichiers à la main dans `trunk`, puis de créer un tag manuellement. Une action GitHub maintenue par la communauté élimine cette friction : elle traduit un push Git en opérations SVN équivalentes, en coulisse.

Ce tutoriel construit ce pipeline de bout en bout. La question de la revue initiale par l'équipe du répertoire WordPress.org, nécessaire avant la toute première publication d'une extension, ne fait pas partie de ce sujet.

## Structurer le dépôt pour distinguer code et distribution

> L'essentiel à retenir : Une action toute prête évite d'apprendre les commandes SVN ; .distignore pour exclure fichiers de dev et dépendances ; Tag automatique déclenché par une release GitHub

Un dépôt Git de développement contient généralement des fichiers qui n'ont rien à faire dans la version distribuée aux utilisateurs finaux : tests, configuration CI, dépendances de développement, fichiers de build source. Le fichier `.distignore`, à la racine, liste ce qu'il faut exclure au moment de la publication, par analogie avec `.gitignore` :

```
.git
.github
.gitignore
.distignore
node_modules
tests
phpunit.xml.dist
composer.json
composer.lock
package.json
package-lock.json
webpack.config.js
src
.editorconfig
README.md
```

Notez que `README.md` (destiné aux développeurs sur GitHub) est exclu, mais le fichier `readme.txt` au format spécifique attendu par WordPress.org, lui, doit être conservé — c'est ce dernier qui alimente la page de présentation de l'extension sur le répertoire officiel.

## Le workflow GitHub Actions

L'action communautaire `10up/action-wordpress-plugin-deploy` encapsule toute la mécanique SVN. Le workflow se déclenche à la publication d'une release GitHub :

```
name: Déploiement WordPress.org
on:
  release:
    types: [published]

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

      - name: Installer les dépendances de production
        run: composer install --no-dev --optimize-autoloader

      - name: Déployer vers WordPress.org
        uses: 10up/action-wordpress-plugin-deploy@stable
        env:
          SVN_USERNAME: ${{ secrets.SVN_USERNAME }}
          SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
```

Les identifiants SVN — ceux du compte WordPress.org de l'auteur de l'extension — sont stockés en secrets protégés du dépôt GitHub, jamais en clair dans le fichier de workflow.

## Gérer les assets visuels (icône, bannière, captures d'écran)

Les éléments visuels de la page du répertoire (icône, bannière, captures d'écran) vivent dans un dossier `.wordpress-org` à la racine du dépôt Git, séparé du code de l'extension lui-même :

```
.wordpress-org/
├── icon-128x128.png
├── icon-256x256.png
├── banner-772x250.png
└── screenshot-1.png
```

L'action de déploiement synchronise automatiquement ce dossier vers le répertoire `assets` du dépôt SVN, distinct de `trunk`, sans qu'il soit nécessaire de le référencer explicitement dans `.distignore`.

## Synchroniser le numéro de version

WordPress.org attend une cohérence stricte entre trois emplacements : l'en-tête du fichier principal du plugin, la constante de version PHP éventuelle, et le champ `Stable tag` du `readme.txt`. Une divergence entre ces valeurs peut entraîner un mauvais affichage de version sur la page du répertoire, voire empêcher WordPress d'informer les utilisateurs d'une mise à jour disponible.

- En-tête du fichier principal : `Version: 2.4.0`
- `readme.txt` : `Stable tag: 2.4.0`
- Éventuelle constante PHP : `define( 'MON_PLUGIN_VERSION', '2.4.0' );`

Un petit script exécuté en amont du workflow, ou un outil comme `release-please`, peut automatiser cette synchronisation pour éviter l'erreur humaine classique d'un oubli sur l'un des trois emplacements.

## Cycle complet, du tag Git au tag SVN

> Une fois ce pipeline en place, publier une nouvelle version d'extension revient à créer une release GitHub avec le bon numéro de tag — le reste, y compris la mécanique SVN que je ne maîtrise toujours pas dans le détail, se déroule automatiquement.

```
git tag v2.4.0
git push origin v2.4.0
# Puis créer la release depuis l'interface GitHub, ou :
gh release create v2.4.0 --title "2.4.0" --notes "Voir CHANGELOG.md"
```

La création de la release GitHub déclenche automatiquement le workflow, qui pousse le contenu du dépôt (filtré par `.distignore`) vers `trunk`, crée le tag SVN correspondant, et synchronise les assets visuels — sans qu'aucune commande SVN n'ait été tapée manuellement.

## Pour aller plus loin

Ce pipeline supprime la barrière technique de SVN pour les équipes qui ne travaillent qu'en Git au quotidien, sans nécessiter d'apprendre ses commandes. Le point de vigilance principal reste la rigueur du `.distignore` : un oubli peut publier accidentellement des fichiers de développement, voire des identifiants de test, sur le répertoire public de WordPress.org.