Abbiamo uno script NAnt per aggiornare i nostri assembly "pre-costruiti" in TFS come uno dei nostri progetti di costruzione TeamCity. La build è attivata da altre build. Fa un checkout TF, sposta alcuni file, quindi esegue un controllo TF.Errore TF: non ci sono modifiche rimanenti da verificare
Il target rilevante (tf risolve al percorso di tf.exe):
<target name="checkin.assemblies">
<exec program="${tf}">
<arg value="checkin" />
<arg value="${dir.assemblies}" />
<arg value="/comment:${message}." />
<arg value="/noprompt" />
<arg value="/recursive" />
</exec>
</target>
Regolarmente otteniamo:
Checking in edit: ... The following changes were not checked in because the items were not modified. Undoing edit: ... There are no remaining changes to check in. External Program Failed: E:\Microsoft Visual Studio 10.0\Common7\IDE\TF.exe (return code was 1) Process exited with code 1 BUILD FAILED - 0 non-fatal error(s), 1 warning(s)
Quello che penso sta accadendo è la build viene innescata una volta di troppo volte (ci sono diverse build che possono attivarlo). Se i file che vogliamo aggiornare non vengono modificati, TFS salta il check-in e restituisce "volentieri" un codice di errore. Sfortunatamente restituirà anche 1 errori "bloccati per il check-out", che sono gravi.
Per riferimento: TF Command-Line Exit Codes
La soluzione è semplice ma fastidioso - sparare una delle build si imbatterà il numero di versione di un assembly e quindi innescare questa build.
Come possiamo rendere questo lavoro affidabile?
Aggiornamento: abbiamo finito per rivedere la costruzione di attivazione configurazioni per TeamCity per creare costruire “catene”, assicurando che il check-in solo si scatta una volta.