2016-06-10 32 views
6

Il mio obiettivo è avere un file composer.json impegnato nel nostro repository di progetto che specifica quale tema (i) o plugin (i) devono essere usati per quel progetto e quando uno sviluppatore abbassa il repository tutto quello che devono fare è eseguire l'installazione di compositore. Vogliamo mantenere i plug-in fuori dal repository del progetto per fermare il gonfiore del repository del progetto e rallentare nel tirare e spingere.Creazione di un repository privato satis composer per temi wordpress e plug-in

Per i plug-in standard wordpress come "Jetpack by WordPress.com" questo va bene dato che useremo https://wpackagist.org/. Tuttavia, per i Premium pagati per plug-in e quelli personalizzati in casa che non possono essere aperti, desideriamo ospitarli in un repository di Composer privato.

Poiché avremo più versioni di questi plugin, vorrei che tutte le versioni mostrassero come 1.1, 1.2, 1.3 in modo che lo sviluppatore possa specificare nel compositore.json quale versione è richiesta, ad es. se una versione futura rompe qualcosa e abbiamo bisogno di tornare alla versione precedente.

Ho letto le nozioni di base sull'impostazione di un repository privato Satis che ho fatto ma non riesco a farlo scorrere tra i tag git delle versioni e inoltre specificare che è un plugin Wordpress e installarlo nel corretto Posizione.

Questo è stato il mio primo tentativo in cui si ottiene tutto git etichettato versioni:

{ 
    "name": "Private Repository", 
    "homepage": "http://packages.privaterepo.com", 
    "repositories": [ 
     { 
      "type": "vcs", 
      "url": "[email protected]:companyname/project.git" 
     } 
    ], 
    "require-all": true 
} 

E questo è uno dove devo specificare la versione, ma farlo da installare in Wordpress corretto plugin di posizione:

{ 
    "name": "Private Repository", 
    "homepage": "http://packages.privaterepo.com", 
    "repositories": [ 
     { 
      "type": "package", 
      "package": { 
       "name": "company/project", 
       "description": "WordPress Plugin", 
       "version": "1.0", 
       "source": { 
        "type": "git", 
        "url": "[email protected]:company/project.git", 
        "reference": "origin/master" 
       }, 
       "type": "wordpress-plugin", 
       "require": { 
        "php": ">=5.3.2", 
        "composer/installers": "*" 
       } 
      } 
     } 
    ], 
    "require-all": true, 
    "require-dependencies": true, 
    "extra": { 
     "installer-paths": { 
      "wp-content/plugins/{$name}/": ["type:wordpress-plugin"] 
     } 
    } 
} 

Qualcuno può consigliare come far funzionare entrambi questi scenari?

+0

faccio qualcosa di molto simile a te e l'unica differenza che posso vedere è che io non uso require-tutto Ho bisogno di tutti loro uno per uno (quindi "richiedere": {poi una lista). Questo funziona bene per me e per i plugin privati ​​installare con quelli wpackagist ecc ... –

+0

Quale versione del codice Si riferisce al primo o al secondo? –

+0

Mi dispiace Phil, il secondo. E per il riferimento Under source) stavo usando il tag. –

risposta

0

Penso di avere una configurazione simile: nel repository Satis locale abbiamo entrambi i pacchetti interni da un server Git privato e tutti i pacchetti esterni da Github.

Il trucco consiste nel fare due passaggi: il primo passaggio estrae solo i metadati di tutti i pacchetti esterni, ed è qui che entra in gioco l'intervallo di versione per evitare di trascinare TUTTO.

Il secondo passo sarà la scansione attraverso tutti i pronti contro termine Git locali e rilevare tutte le versioni, e inoltre aggiungerà il repo Composer creato nel passaggio 1.

efficacemente avrete a che fare con due configurazioni di Satis che creerà due risultati, e il risultato del primo lavoro per i pacchetti esterni recupererà solo tutti i metadati e, nel secondo passaggio, verrà importato e utilizzato proprio come un repo Git locale e configurando il secondo passo per cercare le versioni "tutte" e possibilmente creare file ZIP da creeranno una copia di backup locale di ogni pacchetto che potrebbe essere necessario.

O in altre parole:

satis-external.json

{ 
    "repositories": [ 
     { 
      "type":"composer", 
      "url":"https://packagist.org" 
     } 
    ], 
    "require": { 
     "any/package":">=2.0" 
    } 
    "output-html": false, 
    "require-dependencies": true 
} 

eseguirlo:

php -dmemory_limit=2G satis/bin/satis build satis-external.json external/ 

satis-interno.JSON

{ 
    "repositories": [ 
     { 
      "type": "composer", 
      "url": "http://url/from/external/above" 
     }, 
     { 
      "type": "vcs", 
      "url": "ssh://internal/gitrepo.git" 
     } 
    ], 
    "require-all": true, 
    "archive": { 
     "directory": "dist", 
     "format": "zip", 
     "prefix-url": "https://whatever/youneed", 
     "skip-dev": true 
    } 
} 

Esegui questo

php -dmemory_limit=2G satis/bin/satis build satis-internal.json internal/ 

Aggiunta di un repository "type = compositore" in Satis farà che si comportano come qualsiasi altro repository - soprattutto sarà scaricare tutti i pacchetti citati lì se "bisogno-all = true ", quindi fai attenzione a non aggiungere Packagist o qualsiasi altro repo direttamente.

Si noti inoltre che "require-dependencies" è vero per i pacchetti esterni perché probabilmente non si vuole passare attraverso la seccatura di aggiungere ogni dipendenza dei pacchetti che si desidera utilizzare.

Se alcuni dei pacchetti a pagamento offrono l'accesso repo remoto, è possibile aggiungere questo repo nella configurazione esterna insieme con le credenziali di accesso - dovrebbe funzionare.

+0

Oh, fantastico: un voto di -1 senza commentare ciò che non ha aiutato quell'utente. – Sven

Problemi correlati