Azure Devops che esegue due build in sequenza

Question

Abbiamo installato Azure Devops. In questo momento il nostro progetto verrà costruito due volte.

Una volta durante l'archiviazione della richiesta di pull nel file YAML e un'altra a causa delle impostazioni di compilazione (immagine sotto).

Ciò attiva due build e fa raddoppiare il nostro tempo di build. Il nostro team Devops ha affermato che questa è una pratica regolare. Perché Azure Devops non attiva solo una build e o è più sicuro fare pratica con due build?

Answer 1

Perché Azure Devops non attiva solo una build e o è più sicuro fare pratica con due build?

Per quanto ne so, questo è il flusso di lavoro previsto di Azure Devops.

a causa delle impostazioni di build

Questo è il trigger della richiesta di pull .

Questo trigger si verifica durante il processo di richiesta pull, il trigger PR deve essere eseguito ogni volta che viene creato un PR.

Questo trigger equivale a un passaggio di verifica, il file non è realmente impegnato nel ramo di destinazione (pre-unito a Targer Branch).

È possibile controllare i risultati della compilazione per determinare se il codice del ramo di origine è valido.

Per esempio:

Se il trigger della richiesta pull non riesce, è possibile rifiutare la richiesta pull. Non influisce sul ramo di destinazione, il ramo di destinazione rimane nello stato originale

Pull Request Checkin nel file YAML

Questo potrebbe essere il trigger CI .

Questo trigger avverrà quando la richiesta pull è stata completata.

In questo caso, il ramo di destinazione è cambiato. La modifica del ramo di destinazione attiva il trigger CI. Questo può ricontrollare se il codice è valido.

Riepilogo del flusso di lavoro ：

Crea richiesta pull -> Trigger richiesta pull (controllo pre-unito e firest) -> Completa richiesta pull -> trigger CI (completa l'unione dei rami e il secondo controllo).

A proposito, se desideri escludere alcuni file in modo che non attivino il trigger di richiesta pull, puoi aggiungere un filtro di percorso.

Per esempio:

Answer 2

Funzionalmente le due build potrebbero non essere sempre le stesse.

Diciamo che hai l'esempio seguente. Le lettere maiuscole sono commit e le lettere minuscole sono potenziali commit.

  e e'
 /   \
|  |   D
C  |   B 
 \ |  /
   A

Questo mostra, due rami provenienti dal commit A (ramo master). Ogni feature branch aveva un PR creato per ognuno. Un ramo ha una build sull'e commit e l'altro ramo ha una build sull'e 'commit. Gli sviluppatori di Azure non possono essere sicuri di quale PR verrà unita per prima.

Una volta uniti entrambi i PR, ti ritroverai con un nuovo commit nel master che non è stato creato in precedenza. Questo è descritto qui

   F
   E \
 / |   D
C  |   B 
 \ |  /
   A

Se vuoi eliminare la necessità della build on master, puoi impostare la scadenza della build su Immediately when branch name is updated