2015-01-29 13 views
6

Ho una configurazione di build con una radice VCS di test che si collega al ramo git dev, 3 passaggi di build e 1 trigger. Questi sono i miei punti di build:Esecuzione di test sui rami di funzionalità

  • Costruire test
  • eseguire test
  • Corporatura & Deploy

vorrei correre tutte queste istruzioni di generazione per la produzione d'dev ma solo due di loro (compilare ed eseguire test) per rami corrispondenti a feature/*. Voglio che questo sia visualizzato sotto la mia configurazione di build. Quindi la configurazione di build ha un ramo predefinito dev che esegue test e distribuisce, ma i rami aggiuntivi feature/* eseguono solo test.

Come posso ottenere questo risultato?

Se aggiungo /refs/heads/(feature/*) alla specifica di ramo (sotto il ramo predefinito), funziona perfettamente, ma viene sempre implementato, cosa che non desidero.

enter image description here

Edit 1: Sembra che ci sia una variabile denominata disponibili %teamcity.build.branch% che è possibile utilizzare. Ma come fare un condizionale nella fase di distribuzione per verificare se il ramo è il ramo dev. Non ne sono sicuro.

Modifica 2: C'è anche un nome di variabile %vcsroot.branch% che è il nome del ramo predefinito nella radice VCS. Pertanto, è ancora necessaria una condizione per verificare se la variabile %teamcity.build.branch% è uguale a %vcsroot.branch%, quindi eseguire il passaggio di distribuzione.

+0

La richiesta di funzionalità di 4 anni è qui: https://youtrack.jetbrains.com/issue/TW-17939 – Arjan

+0

Esattamente, ecco perché lasciare TeamCity è sulla nostra tabella di marcia. – Gaui

risposta

5

Il modo per ottenere quello che vuoi è dividere la tua build in 2 build e avere dipendenze tra di loro. allora puoi avere trigger separati tra le build.

Quindi dividere la costruisce in modo da avere costruire una che contiene

  • test Costruire
  • eseguire test

e costruire B che contiene

  • Corporatura & Deploy

Dare alla build B una dipendenza di istantanea sul build A.

Quindi aggiungere un trigger per creare A quando viene rilevato un check-in VCS. Ciò garantirà che la generazione e i test vengano eseguiti su qualsiasi ramo di funzionalità.

Aggiungete anche un trigger su build B quando viene rilevato un check-in VCS, ma modificate le regole in modo da escludere i rami delle feature.Quando viene rilevato un check-in su qualsiasi altro ramo, viene avviato il build B, ma è necessario prima compilare A, quindi verrà prima accodato e non verrà avviato se la build A non riesce (presumendo che l'opzione sia stata impostata nelle opzioni)

UPDATE Se questo è troppo fastidio, allora si potrebbe essere in grado di svolgere un piccolo trucco, ma la creazione di un passaggio di generazione tra i test Run e creare e distribuire che chiama una riga di comando o uno script PowerShell. Chiamare lo script passando in %teamcity.build.branch% e quindi lo script può verificare se è stato chiamato con dev e Exit 0 se così e Exit -1 in caso contrario e questo passaggio dovrebbe quindi fallire la generazione e impedire la distribuzione. Ciò significa che la build sembrerà fallita, ma impedirà il passaggio che vuoi evitare di eseguire. Potrebbe essere possibile che teamcity non segnali la compilazione come fallita se questo passaggio fallisce, non sono sicuro

L'altra opzione è che si scrive uno script che esegue la compilazione e la distribuzione manualmente e quindi si chiama questo passaggio di script nello %teamcity.build.branch% e uscire anticipatamente se non è dev e continuare solo a fare la build effettiva e distribuire se è dev. questo non si tradurrà in una build fallita, ma significa che devi scrivere script per fare ciò che TeamCity sta facendo per te ora.

+0

Ci deve essere un altro modo più semplice? Abbiamo oltre 100 configurazioni di build (test/staging/live). Questo è troppo fastidio. – Gaui

+0

Non hai menzionato alcun vincolo sul numero di configurazioni di build. Credo che questo sia il modo "corretto", ma aggiornerò la risposta con un trucco che * potrebbe * funzionare. –

+0

Grazie gentilmente. – Gaui

1

È possibile eseguire questa operazione creando un passaggio di build "test" (ad esempio script di PowerShell) per verificare se lo %teamcity.build.branch% corrisponde al modello feature/*. Si eseguono solo i seguenti passaggi (in questo caso Build & Deploy) se i passaggi precedenti hanno avuto esito positivo. Ovviamente il passaggio "test" non dovrebbe fallire la build.

Problemi correlati