build TFS 2015: è possibile utilizzare le variabili nei mapping di repository?

Question

Quando si crea un build vNext su TFS 2015 è possibile definire variabili, che vengono quindi utilizzate nelle fasi di creazione e che possono anche essere utilizzate come variabili di ambiente negli script eseguiti dalla generazione.

La build su cui sto lavorando esegue script che estraggono file da percorsi mappati, quindi sarebbe bello se potessi definire una variabile e usarla in una mappatura in modo che, ad esempio, se aggiorno un riferimento nel progetto, il build sta costruendo, posso semplicemente aggiornare la variabile con la nuova posizione e fare in modo che i mapping e gli script del repository vengano estratti correttamente dalla nuova posizione senza dover apportare modifiche in più posizioni.

Ho provato a fare questo impostando la variabile e la mappatura come segue, Ma questo genera un errore quando si tenta di salvare la build lamentano che ci sono due '$' caratteri nella mappatura. C'è un modo per fare questo o non è attualmente possibile?

Answer 1

È impossibile. Proprio come il messaggio di errore menzionato: ci sono due caratteri '$' nella mappatura. Il che significa che il percorso dell'applicazione non dovrebbe variare da una build all'altra.

Mapping nella pagina Repository vengono utilizzati per specificare controllo del codice sorgente cartella che contiene i progetti che devono essere costruiti nella build definizione. È possibile impostarlo facendo clic sul pulsante Ellipsis (...), tuttavia, non è possibile includere variabili nel percorso di mappatura.

C'è una domanda simile: Variables in TFS Mappings on Visual Studio Online Team Builds

Answer 2

Questo è stato mi ha causato Havok per un bel po 'pure.

Per i principianti, esiste una richiesta di servizio per questa funzione. Puoi aggiungere i tuoi voti e inserire qui per ottenere Microsoft per consentire questa funzionalità: https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/14131002-allow-variables-in-repository-variables-and-trigg

In secondo luogo, abbiamo sviluppato una soluzione che ci ottiene la maggior parte del modo lì. Non è perfetto, ma potrebbe esserti utile se sei a tuo agio con i compromessi o se riesci a ovviare alle carenze.

Inizia disattivando l'opzione "Origini etichetta" della build e mappando il campo Percorso server alla build di base. Vorrete aggiungere una variabile personalizzata alla definizione di costruzione per dire all'istanza di costruzione quale posizione TFS da cui estrarre. Per esempio, abbiamo un progetto di base e rami quindi più dal progetto, così la nostra fonte è strutturato come questo

$\Team Project\Project1 
$\Team Project\Project1Branch1 
$\Team Project\Project1Branch2 
$\Team Project\Project1Branch3 

e creiamo una variabile denominata "filiale" che siamo in grado di impostare su "Branch1", "Branch2 ", e così via.

Quando vogliamo creare il progetto di base, lasciamo vuota la variabile Branch quando avviiamo la build. Per le build del ramo, lo impostiamo sul nome del ramo che vogliamo costruire.

Poi i nostri passi di compilazione simile a questa

• Remap Workspace cartella per Branch cartella
• ottenere i file per Branch specificato - Dobbiamo farlo manualmente dopo rimappatura il nostro spazio di lavoro
• compilare il sorgente in il ramo specificato
• Pubblica manufatti di costruzione dal ramo specificato
• Contrassegnare manualmente il codice del ramo specificato

Il compito Remap corre il comando

tf workfold "$/Team Project/Project1$(Branch)" "$(build.sourcesDirectory)\$(Build.DefinitionName)$(Branch)" 

Il compito Get manuale esegue il comando seguente

get /recursive /noprompt "$/Team Project/Project1$(Branch)" 

La build utilizza la variabile Branch per puntare alla posizione corretta del file di soluzione per il ramo specificato

$(build.sourcesDirectory)\$(Build.DefinitionName)$(Branch)\SolutionFile.sln 

The Publ ish compito Artefatti utilizza la variabile Sede in entrambi il campo dei contenuti e l'esempio campo Percorso nel Sommario

**\$(Build.DefinitionName)$(Branch)\bin 

Il Label compito codice utilizza il seguente comando

tf label "$(build.buildNumber)" "$/Team Project/Project1$(Branch)" /recursive 

L'aspetto negativo di questa configurazione è che si non acquisire modifiche e articoli di lavoro associati alle filiali secondarie poiché il campo Percorso server è sempre impostato sulla posizione principale. Questo potrebbe non essere un problema se ti unisci sempre dalle tue filiali alla tua posizione principale prima di avviare una build destinata alla produzione. Quello che puoi fare per compensare questo dipende molto dal tuo caso d'uso.

Con alcuni aggiustamenti, è possibile utilizzare questo stesso formato per specificare anche percorsi completi se necessario.