2014-10-25 19 views
5

ho appena TeamCity configurazione per automatizzare la nostra costruisce, la nostra soluzione attuale ha sia un dev e ramo principale. Quello che sto cercando di ottenere è di far compilare e pubblicare il ramo di sviluppo su un feed NuGet di sviluppo sulla nostra installazione ProGet e quindi pubblicare la filiale principale sul nostro feed NuGet principale sul server ProGet.Publishing Nuget Pacchetti - TeamCity

Stiamo usando la distribuzione di polpo per distribuire i pacchetti, all'interno di TeamCity abbiamo installato il plugin di polpo installato e se spunta la casella per eseguire OctoPack crea i pacchetti e appaiono come artefatti al termine della compilazione. Se cerco di usare il pacchetto NuGet costruire passo nella TeamCity ottengo il seguente errore per uno dei nostri progetti:

[08:33:49] :   [pack] Attempting to build package from 'xxx.csproj'. 
[08:33:50]W:   [pack] Unable to find 'xxx.exe'. Make sure the project has been built. 

Il progetto è stato costruito e funziona con OctoPack quindi perché non sta funzionando con il NuGet in valigia? Wwe ha cinque progetti in costruzione e i primi quattro funzionano bene, uno è un'app console, uno è un sito Web mvc e due sono librerie di classi. Quello che non funziona è un servizio di Windows.

L'obiettivo finale è quello di pubblicare questi pacchetti a un feed privata Proget. Non mi dispiace usare OctoPack ma nella mia testa volevo rimuovere quella dipendenza da TeamCity ma posso conviverci. Tuttavia, quando provo a utilizzare il tipo di runner NuGet Publish, come faccio a selezionare di pubblicare qualsiasi artefatto NuGet che è stato creato?

Sono stato googling come un pazzo e non riesco a trovare tutti i link utili che descrivono ciò che si suppone di entrare, vorrei davvero apprezzare qualsiasi utile commenti/risposte.

Stiamo usando la versione 8.15 di TeamCity.

+0

Quali argomenti stai passando a 'nuget pack'? Sembra che ci siano più domande qui, potresti prendere in considerazione la possibilità di suddividerle in modo che siano meno accoppiate. Le migliori domande di Stack Overflow sono quelle che possono aiutare anche altre persone. –

+0

Quindi, è un approccio un po 'diverso, ma dal momento che vuoi semplificare il tuo approccio di distribuzione, che ne pensi di implementare appena usciti da TeamCity? [BuildMaster] (http://inedo.com/buildmaster/extensions/teamcity) può importare e distribuire le build di TeamCity senza dover necessariamente coinvolgere NuGet. Disclaimer: lavoro per inedo. –

risposta

9

Speriamo che la seguente vi aiuterà con almeno parte della sua domanda; principalmente il bit relativo alla modalità di pubblicazione degli artefatti impacchettati.

NuSpec approccio

Quando si utilizza il passo NuGet Pack compilazione, è possibile specificare il Output Directory, che determinerà la posizione di uscita dei pacchetti. È possibile specificare questo come un percorso relativo alla directory di cassa, probabilmente meglio definirlo come parametro di generazione, come ad esempio %system.PackageDeployOutput% come userete nel prossimo passo ...:

Avanti, specificare una NuGet Publish costruire passo, inserire la chiave di origine Contenitore/API, ecc, e specificare i pacchetti da caricare

%system.PackageDeployOutput%\*.nupkg

Questo pick up l'uscita dei pacchetti nel passaggio precedente. L'ho usato abbastanza efficacemente e l'approccio di parametrizzazione incoraggia le convenzioni su tutte le tue build.

OctoPack Supporto

Se si utilizza il passaggio di generazioneMsBuild con OctoPack, è possibile utilizzare un approccio simile dichiarando un parametro di sistema denominato

system.OctoPackPublishPackageToFileShare = %teamcity.build.checkoutDir%\%system.PackageDeployOutput%(notare la stessa parametri come sopra)

è possibile dichiarare queste come parametri di progetto radice, in modo da ottenere l'essere st di entrambi i mondi.Il mio approccio preferito al packaging è attualmente quello di utilizzare i file nuspec per gli endpoint implementabili. Ho rilevato che OctoPack è un po 'sovraccarico quando si tratta di implementazioni più complesse (va bene per i progetti base di MsBuild).