Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Travis CI

Come distribuire un plugin WordPress da TravisCI a WordPress.org

by
Difficulty:BeginnerLength:ShortLanguages:

Italian (Italiano) translation by Mariano Serafini (you can also view the original English article)

Non tutti amano la subversion. Se si utilizza Git per gestire lo sviluppo di plugin di WordPress, mantenere sincronizzati il repository Git e il repository di WordPress.org SVN è noioso. Fortunatamente, possiamo usare il fornitore di distribuzioni di TravisCI per automatizzare la distribuzione SVN dopo i test.

Prerequisiti

Hai bisogno di questi prima di continuare:

  1. Account GitHub
  2. Account TravisCI
  3. Codice sorgente del plugin
  4. Repository SVN del plugin di WordPress.org (Si ottiene dopo l'approvazione della revisione del plugin.)

Primo invio a GitHub

Per poter utilizzare TravisCI, dobbiamo ospitare il repository del plugin su GitHub.

Innanzitutto, creiamo un nuovo repository su GitHub andando su questa pagina e compilando il nome del repository.

create new GitHub repository
GitHub new repository page

Quindi, andremo a fare una commit di tutti i file di plugin in Git e lo invieremo al repository GitHub. Ricorda di sostituire l'URL remoto con il tuo.

Collegare TravisCI

Connetti il ​​tuo repository GitHub con TravisCI andando alla pagina del tuo account TravisCI e attivando il tuo repository. Fai clic su Sincronizza l'account nell'angolo in alto a destra se il repository appena creato non viene visualizzato nell'elenco.

TravisCI account settings

Tutto pronto. Ogni volta che invierete nuove commit o qualcuno farà una pull request a GitHub, innescherà una build su TravisCI.

Prima build su TravisCI

TravisCI utilizza un file YAML denominato .travis.yml nella radice del repository per personalizzare le build. Scopri come è possibile controllare il ciclo di vita della build nel documento di personalizzazione della build.

Questo è un file di configurazione di base che istruisce TravisCI per eseguire le build su PHP 7.0 e 7.1. Poiché i test non rientrano nell'ambito di questo tutorial, ho sostituito i comandi di test effettivi con echo 'Tested'.

Fai una commit del file e invialo a GitHub. La build diTravisCI verrà attivata automaticamente.

TravisCI current build

Aggiunta della configurazione del provider di distribuzione

I provider di distribuzione vengono eseguiti se i test passati e i condizionali predefiniti (la sezione on) sono soddisfatti. TravisCI fornisce quasi 40 fornitori ufficiali di distribuzione. Purtroppo, nessuno di loro supporta i repository di subversion di WordPress.org. Così ho creato il mio fornitore personalizzato. Potete trovarlo su GitHub, e anche la sua pull request.

Per utilizzarlo, aggiungere queste righe alla fine di .travis.yml.

Spiegazione della configurazione

before_deploy

La sezione before_deploy copia tre file nella directory build che deve essere controllata nel repository di subversion di WordPress.org. Nel mondo reale, questo è dove si preferisce eseguire gulp o grunt per preparare il plugin pronto per la produzione.

Non copiare i file di test o i file non necessari in build perché l'intera directory build viene rilasciata agli utenti, e gli utenti non necessitano dei file di test.

provider e edge

Diciamo a TravisCI di installare il mio fornitore dalla branch add-wordpress-plugin-deployment https://github.com/TypistTech/dpl. Una volta che la pull request è stata unita, la parte edge non è necessaria.

on

La sezione on controlla se una distribuzione deve essere eseguita. La distribuzione viene attivata solo quando tutti i requisiti sono soddisfatti.

Nell'esempio precedente, si distribuisce a WordPress.org solo quando:

  1. è una build PHP 7.1
  2. è un commit con tag
  3. è attivato dal repository TangRufus / tutsplus-dpl-demo (le forks e le pull requests non avrebbero attivato la distribuzione)

slug

Lo slug del plugin.

Se l'URL del tuo plugin è https://wordpress.org/plugins/my-awesome-plugin/, allora my-awesome-plugin è lo slug del plugin.

nome utente

Il tuo nome utente dell'account di WordPress.org con il quale hai inviato il plugin per l'approvazione della revisione.

password

La password dell'account WordPress.org. Non salvare mai questa password in .travis.yml in testo semplice!

Nell'esempio precedente, utilizziamo la variabile di ambiente $WORDPRESS_ORG_PASSWORD, che può essere impostata sulla dashboard web di TravisCI. Scegliere Impostazioni dal menu cog e fare clic su Aggiungi nella sezione Variabili dell'ambiente. Non abilitare mai l'opzione "Visualizza il valore nel registro della build"!

TravisCI-environment-variables-settings

build_dir

Tutto quello che si trova in questa directory sarà inviato nel repository di subversion di WordPress.org, cioè sarà incluso nel file zip scaricabile.

Abbiamo impostato questo a build perché abbiamo copiato i file del plugin in build durante il before_deploy.

Assegnare i tag

Supponiamo di aver risolto alcuni bug e siamo pronti a pubblicare una nuova versione su WordPress.org.

Questi comandi fanno una commit delle modifiche al master branch ma non attivano una distribuzione:

Solo le commit taggate attivano una distribuzione:

Risultati

Tornate a TravisCI e aprite il registro di build di PHP 7.1. Dovresti vedere che una distribuzione è registrata.

E sul tracciato WordPress.org (https://plugins.trac.wordpress.org/browser/<slug-del-plugin>):

WordPress plugin subversion trac

Avvertenze

svn commit due volte

Dal momento che TravisCI viene fornito con una vecchia versione di subversion che non funziona bene con le sottodirectory, faccio svn commit due volte.

Il primo svn commit rimuove tutto quello che si trova in trunk. Il secondo svn commit copia tutto da build_dir a trunk.

Sperimentale

Questo fornitore è ancora sperimentale e non è unito al servizio ufficiale di TravisCI. È possibile tenere traccia dei commenti di TravisCI sulla sua pull request.

Usando edge non si unisce la mia branch nel master originario. C'è la possibilità che la mia branch sia arretrara rispetto al repository ufficiale. Quando succede, puoi fare un fork della mia branch, quindi cambiare source in .travis.yml nel tuo repository GitHub.

Ricapitolando

Per utilizzare questo provider di distribuzione:

  1. Mantieni il repository del plugin su GitHub.
  2. Collega GitHub e TravisCI.
  3. Aggiungi la configurazione a .travis.yml.
  4. Fai una push di un tag.

Spero che tutto questo ti aiuti a distribuire i plugin a WordPress.org più velocemente.

WordPress ha un'economia incredibilmente attiva. Ci sono temi, plugin, librerie e molti altri prodotti che ti aiutano a costruire il tuo sito e il tuo progetto. La natura open-source della piattaforma lo rende inoltre un'ottima opzione per migliorare le tue capacità di programmazione. Qualunque sia il caso, puoi vedere tutto ciò che abbiamo sul marketplace Envato.

Grazie per l’attenzione.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.