GitHub Actions per lo sviluppo di plugin WordPress

Quinto articolo della serie sui fondamenti dello sviluppo di plugin WordPress. Abbiamo un repository Git, Composer e un ambiente locale con wp-env. Ora automatizziamo i controlli di qualità con GitHub Actions.

Finora ogni verifica sul tuo codice è stata manuale: esegui un comando, guardi il risultato, vai avanti. Funziona, ma è facile dimenticarsi un controllo — specialmente quando il progetto cresce. La Continuous Integration (CI) risolve questo problema: ogni push e ogni Pull Request attivano controlli automatici, senza che tu debba fare nulla.

Alla fine di questo articolo avrai un workflow GitHub Actions funzionante che verifica il tuo plugin a ogni modifica.

Cos’è GitHub Actions

GitHub Actions è la piattaforma CI/CD integrata in GitHub. Non servono servizi esterni né configurazioni complicate — tutto vive nel tuo repository.

I workflow sono file YAML nella cartella .github/workflows/. Si attivano in risposta a eventi come push, Pull Request o anche secondo una pianificazione. Per i repository pubblici, i minuti di esecuzione sono illimitati.

Qualche termine che incontrerai: un workflow contiene uno o più job, ogni job è composto da step, e il tutto gira su un runner — una macchina virtuale messa a disposizione da GitHub.

Il primo workflow

Creiamo il file .github/workflows/ci.yml:

yaml

name: CI

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

jobs:
  checks:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
          tools: composer

      - name: Install dependencies
        run: composer install --no-interaction --prefer-dist

      - name: Validate composer.json
        run: composer validate --strict

Vediamolo passo per passo. Il workflow si attiva su ogni push e Pull Request verso main. Gira su un runner Ubuntu fornito da GitHub. I quattro step fanno esattamente quello che faresti in locale: scaricano il codice, configurano PHP, installano le dipendenze Composer e verificano che composer.json sia valido.

Anche questo workflow minimale ha già un valore: cattura configurazioni Composer rotte e dipendenze mancanti prima che diventino un problema.

Aggiungere controlli di qualità

Il workflow sopra è uno scheletro. Nei prossimi articoli aggiungeremo i singoli strumenti — ma prepariamo già la struttura.

Prima di tutto, aggiungi una sezione scripts al tuo composer.json:

json

{
    "scripts": {
        "phpcs": "phpcs",
        "phpstan": "phpstan analyse",
        "test": "phpunit"
    }
}

Questi script Composer sono il collante tra sviluppo locale e CI: gli stessi comandi funzionano ovunque. Nel workflow, aggiungere un controllo diventa una sola riga:

yaml

      - name: Check coding standards
        run: composer run phpcs

      - name: Run static analysis
        run: composer run phpstan

      - name: Run tests
        run: composer run test

Non preoccuparti se questi strumenti non sono ancora installati — li configureremo uno per uno nei prossimi articoli. L’importante è che la struttura sia pronta.

Matrice PHP e WordPress

Un plugin dovrebbe funzionare su più versioni di PHP. Con GitHub Actions puoi testarlo automaticamente grazie alla strategy matrix:

yaml

jobs:
  checks:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        php-version: ['8.1', '8.2', '8.3']

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php-version }}
          tools: composer

      - name: Install dependencies
        run: composer install --no-interaction --prefer-dist

      - name: Validate composer.json
        run: composer validate --strict

Con queste poche righe, il workflow gira tre volte in parallelo — una per ogni versione di PHP. Puoi estendere la matrice anche con diverse versioni di WordPress, ad esempio variando la configurazione di wp-env. Per iniziare, concentrati sulle versioni PHP: è lì che si nascondono le incompatibilità più comuni.

Pull Request come punto di controllo

Ricordi il workflow con i branch dall’articolo su Git? Ora il cerchio si chiude. Quando apri una Pull Request, GitHub esegue automaticamente il workflow e mostra il risultato direttamente sulla PR: verde se tutto passa, rosso se qualcosa fallisce.

Puoi anche attivare le branch protection rules nelle impostazioni del repository per impedire il merge finché i controlli non passano. Questo trasforma ogni PR in un checkpoint di qualità automatico: branch → PR → controlli automatici → merge con fiducia.

Prossimi passi

Ora hai una pipeline CI che gira a ogni push e Pull Request, con una matrice che copre più versioni di PHP. Il workflow è ancora uno scheletro — ma è progettato per crescere.

Nel prossimo articolo configureremo PHPCS con gli standard WordPress (WPCS) per verificare automaticamente lo stile del codice. Aggiungeremo lo strumento via Composer e il relativo step al workflow CI che abbiamo creato oggi.

Prossimo articolo: Coding Standards con PHPCS e WPCS →