Utilizzo di Composer e Repository privato su GitHub utilizzando VCS su Build Server

Il mio compsoser.json utilizza 2 repository privati ​​dal nostro account Github dell'organizzazione ed è il seguente.

{ "name": "API", "repositories": [ { "type": "vcs", "url": "git@github.com/company/private.git" }, { "type": "vcs", "url": "[email protected]/company/private2.git" } ], "require": { "php": ">=5.3.3", "zendframework/zendframework": ">2.1.3", "doctrine/mongodb-odm": "dev-master", "doctrine/doctrine-mongo-odm-module": "dev-master", "company/private": "dev-master", "company/private2": "dev-master" } } 

Abbiamo configurato le chiavi SSH e le abbiamo aggiunte alle chiavi autorizzate sul nostro server di staging. Quando eseguiamo git clone funziona perfettamente e non richiede alcuna credenziale.

Tuttavia, quando eseguiamo l'aggiornamento di Composer, il recupero dei repository non riesce perché il compositore non ha accesso ai repository.

Poiché viene eseguito in modo non interattivo poiché questo fa parte di uno script di build, non è ansible immettere credenziali e fare in modo che questo venga automatizzato.

Cosa possiamo fare per consentire al compositore di accedere ai nostri repository privati ​​durante la compilazione?

È ansible configurare il compositore per utilizzare i file di chiavi per accedere al repository privato.

Maggiori informazioni: https://getcomposer.org/doc/articles/handling-private-packages-with-satis.md#security

Capisco che il titolo della domanda menzioni specificamente usando type "vcs", ma questo è un metodo alternativo di usare repository git privato per distribuire un progetto come pacchetto.

 "repositories": [ { "type": "package", "package": { "name": "company/private", "version": "0.1.0", "type": "package", "source": { "url": "[email protected]:/company/private.git", "type": "git", "reference": "master" } } } ], "require": { "company/private": "*" } 

La limitazione è che è necessario modificare manualmente il numero di versione each volta che si distribuisce se si desidera l'ultima versione. Tuttavia, questo è anche il suo vantaggio.

La definizione di un repository in questo modo ti consentirà di estrarre una specifica versione con tag . In questo caso il commit con il tag 0.1.0 verrà 0.1.0 composer update .

Dovrai aggiungere le chiavi SSH del server che stai distribuendo nel tuo account github.

Gli URL nella tua domanda originale mancano di due punti:

 "url": "[email protected]/company/private.git" 

dovrebbe essere

 "url": "[email protected]:/company/private.git" 

Ho appena avuto lo stesso problema e questo l'ha risolto.

 "name": "{vendor}/{package-name}", "repositories": [ { "type": "package", "package": { "name": "{vendor}/{package-name}", "version": "{arbitrary-version}", "type": "package", "source": { "url": "[email protected]:{github-username}/{github-repository}.git", "type": "git", "reference": "{branch}" } } } ] "require": { "{vendor}/{package-name}": "*" } 

Ho davvero apprezzato le risposte e la guida; tuttavia, non è riuscito a far funzionare la soluzione per me. E, penso che la risposta potrebbe possibilmente usare qualche dettaglio aggiunto riguardo a ciò che sembra succedere qui.

  • vendor: il nome del fornitore utilizzato nel composer.json del pacchetto.
  • nome-pacchetto: l'utente del nome del pacchetto nel composer.json del pacchetto.
  • versione arbitraria: un numero di versione random; non ha bisogno di esistere come versione in GitHub.
  • github-username: l'account utente GitHub in cui risiede il repository.
  • repository github: il nome del repository GitHub.
  • branch: il branch GitHub da utilizzare quando si verifica il codice.

Le due cose che mi hanno dato il maggior problema erano i due punti (:) non (non dovrebbero?) Essere seguiti da una barra ( / ). Non dimenticare di inserire .git alla fine url .

Punti di congettura e incertezza:

  1. Non sono sicuro di cosa succederebbe se modificassi il membro package.name in qualcosa di non corretto. In altre parole, non so se questo è un riferimento interno per require da solo; o, se ci sarà qualcos'altro che accade lì.
  2. Non sono sicuro che il branch cambi effettivamente qualcosa e non sono in grado di testarlo.