API TFS 2010 - Ottenere gli elementi di lavoro dall'unione

Question

Devo inviare un messaggio di posta elettronica al completamento di una compilazione in TFS 2010 che descrive gli elementi di lavoro associati ai check-in compilati come parte di questa build. Ciò non comporta alcun problema tramite l'uso della variabile associatedChangesets disponibile nel flusso di lavoro di generazione.

Tuttavia, in una situazione di produzione, uniremo le modifiche dal nostro ramo Sviluppo a una filiale di rilascio. A questo punto, la build ritiene che ci sia stata solo una modifica - che è la già citata fusione di Development in Release. Ovviamente questo è abbastanza inutile in quanto abbiamo bisogno di scoprire quali modifiche sono state apportate nel ramo che è stato fuso e gli elementi di lavoro associati.

Qualcuno sa come farlo utilizzando l'API TFS 2010? Sembra essere scarsamente documentato da una prospettiva API. So che è possibile espandere il nodo della cronologia di unione in VS2010, ma ovviamente questo non va bene dato che questi dati devono essere raccolti in modo programmatico in modo che sia possibile inviare un'e-mail di report.

Answer 1

OK ... Penso di aver trovato una soluzione a questo anche se è goffo e la verità viene detta che non sono esattamente sicuro di come funzioni. Ma qui va - forse indicherà qualcuno nella giusta direzione.

var associatedWorkItems = new List<WorkItem>(); 

//Passed in from the build workflow (this variable is available under the 'Run On Agent' sequence as 'associatedChangesets' 
IList<Changeset> associatedChangesets = context.GetValue(BuildAssociatedChangesets); 

if (associatedChangesets.Count > 0) 
{ 
    var projectCollection = 
     new TfsTeamProjectCollection(new Uri("http://localhost:8080/tfs/DefaultCollection")); 
    VersionControlServer versionControlServer = projectCollection.GetService<VersionControlServer>(); 

    foreach (var changeset in associatedChangesets) 
    { 
     //In order to view the individual changes, load the changeset directly from the VCS. 
     Changeset localChangeset = versionControlServer.GetChangeset(changeset.ChangesetId); 

     foreach (Change change in localChangeset.Changes) 
     { 
      //Find out what was merged in. 
      ChangesetMerge[] mergedChangesets = versionControlServer.QueryMerges(
       null, 
       null, 
       change.Item.ServerItem, 
       new ChangesetVersionSpec(localChangeset.ChangesetId), 
       new ChangesetVersionSpec(localChangeset.ChangesetId), 
       null, 
       RecursionType.Full); 

      //Extract work item information from changesets being identified as merged. 
      foreach (var changesetMerge in mergedChangesets) 
      { 
       Changeset actualChange = versionControlServer.GetChangeset(changesetMerge.SourceVersion); 

       foreach (WorkItem item in actualChange.WorkItems) 
       { 
        if (!associatedWorkItems.Exists(w => w.Id == item.Id)) 
        { 
         associatedWorkItems.Add(item); 
        } 
       } 
      } 
     } 
    } 
} 

Non chiedetemi esattamente come QueryMerges opere, ma tutto quello che sto facendo qui dicendo mostrami che cosa che cosa è fusa come parte di un insieme di modifiche check-in. Si noterà che i parametri sono gli stessi ChangesetVersionSpec - questo significa che stiamo solo esaminando le fusioni da questo unico changeset.

Riceverete una matrice di oggetti ChangesetMerge da QueryMerges(). Nella classe ChangesetMerge esiste una proprietà chiamata SourceVersion - questa è la ChangesetId del changeset originale incorporato in. Una volta ottenuto che possiamo usare il metodo VersionControlServer.GetChangeset() per caricare il set individuale ed estrarre il WorkItem. Questo viene poi aggiunto a un elenco di oggetti di lavoro che possono essere manipolati nel modo desiderato (nel mio caso, una e-mail). Ho anche usato il controllo .Exists() per assicurarmi che lo stesso WorkItem non venga registrato due volte.

Si noti che anche se si dispone della raccolta "associatiChangeset" dal flusso di lavoro di generazione, per qualche motivo (almeno per me), la proprietà Changes [] all'interno di "associatedChangesets" non è mai stata popolata (quindi il caricamento di ogni singolo changeset utilizzando il . metodo VersionControlServer.GetChangeset() come questo sembra per popolare in realtà tutti i campi di cui abbiamo bisogno

come ho detto, 1. si tratta di una soluzione di goffo (un sacco di looping - alcuni dei quali è probabilmente unecessary), 2. i don Capisco perfettamente come funziona, anche se sembra che produca i risultati richiesti - sono arrivato a questa conclusione facendo molti test e debugging e infine - è il meglio che ho potuto trovare sulla base della dolorosa documentazione fornita da Microsoft.

Spero che aiuti qualcuno!