2015-12-28 1 views
6

Я пытаюсь выяснить, как закрыть цикл в нашем процессе сборки, где мы применяем номер версии к файлам AssemblyInfo. * Как часть процесса сборки.Как вы регистрируете файлы как часть сборки в Visual Studio Team Services?

Мы находимся в разгаре миграции из наземных станций tfs в визуальные услуги студии студии. Многие из наших текущих встроенных модулей обновляют номер версии, чтобы синхронизировать ее с номером сборки и дополнительно проверять эти файлы на исходный элемент управления во время сборки.

В качестве примера я успешно использовал script located on msdn, чтобы начать настройку процесса сборки.

Я сейчас пытается проверить файлы обратно в систему управления версиями, но я получаю сообщение об ошибке:

#[error]TF30063: You are not authorized to access https://subdomain.visualstudio.com/DefaultCollection. 
#[error]Process completed with exit code 100 and had 1 error(s) written to the error stream. 

настоящее время я использую tf.exe, чтобы попытаться сделать это. Сначала найдите путь к инструменту в верхней части сценария powershell;

# get the tf command line tool path 
$tfexe = [System.IO.Path]::GetFullPath($env:VS140COMNTOOLS + "..\..\common7\ide\tf.exe") 
if (-Not (Test-Path $tfexe)) 
{ 
    Write-Error "Could not find tf.exe at '$tfexe'" 
    exit 1 
} 
else 
{ 
    Write-Host "Found tf.exe at '$tfexe'" 
} 

Затем измените цикл, чтобы получить файл, а затем проверить файлы обратно.

# Apply the version to the assembly property files 
$files = gci $Env:BUILD_SOURCESDIRECTORY -recurse -include "*Properties*","My Project" | 
    ?{ $_.PSIsContainer } | 
    foreach { gci -Path $_.FullName -Recurse -include AssemblyInfo.* } 
if($files) 
{ 
    Write-Host "Will apply $NewVersion to $($files.count) files." 

    foreach ($file in $files) { 

     #Write-Host "Attempting to checkout file '$file'" 
     & ($tfexe) vc checkout $file 

     $filecontent = Get-Content($file) 
     attrib $file -r 
     $filecontent -replace $VersionRegex, $NewVersion | Out-File $file 
     Write-Host "$file.FullName - version applied" 
    } 

    # Checkin pending changes together 
    ##[error]TF30063: You are not authorized to access https://subdomain.visualstudio.com/DefaultCollection. 
    ##[error]Process completed with exit code 100 and had 1 error(s) written to the error stream. 
    Write-Host "Attempting to checkin files" 
    $comment = "Applied $NewVersion to $($files.count) files. ***NO_CI***" 
    & ($tfexe) vc checkin /comment:"$comment" /noprompt 
} 

Является ли это правильный способ делать это? Если службе сборки не разрешен доступ, как он может это ПОЛУЧИТЬ код, скомпилировать его, а затем POST артефакт где-нибудь?

+1

Я предпочел бы отказаться от изменений на 'AssemblyInfo *' файлы, чем проверить их в систему управления версиями.. –

+0

@ JuanM.Elosegui почему? –

+1

Согласовано. поскольку проверенные источники не будут соответствовать тем, которые были записаны в качестве набора изменений, используемого для сборки, не будут соответствовать символам и индексированным источникам, ломать расширенный сценарий отладки, обременять историю и удалять понятие «версий» для большинства разработчиков, вызывая чтобы они не прирастали правильно при проверке изменений, основных версий и т. д. Я рекомендую использовать «1.2. *», и сервер сборки автоматически применяет ревизию, а вручную контролирует основные и второстепенные версии. – jessehouwing

ответ

6

Я не рекомендовал бы проверить в версии сборки каждый раз, вместо этого я бы рекомендовал использовать [assembly: AssemblyVersion("1.2.*")] поддержку подстановочных знаков (и я удалить [AssemblyFileVersion] так это автоматически соответствие.

Проверка в измененные файлы после сборки имеют проблемы несколькими способами:

  • Функция Источники индексов и символы будут использовать источники, которые не соответствуют коду, связанному с набором изменений. будет нарушать расширенные сценарии отладки.
  • Расширенные возможности тестирований ломаются и могут предложить нежелательные тесты или ревизии
  • Истории обрастает **NO_CI** ревизий
  • Он ломает семантические версии, так как эти виды скриптов не фактора в разрушении изменений API и может вызвать забавное поведение.

Я создал новую задачу сборки, которая позволит вам проверить в файлы с помощью задачи:

Добавить его в VisualStudio онлайн в TFS 2015 с использованием консоли tfx:

tfx build tasks upload -taskpath path\to\project\root 

Я все еще работаю над тем, чтобы отложить добавление и удаление, но я столкнулся с проблемами с объектной моделью клиента, так как не ожидал ничего, кроме изменений.

похоже, что вызов tf add и tf delete действительно будет работать в скрипте сборки в сочетании с этой задачей проверки.

Для получения дополнительной информации:

+0

Я предполагаю, что пока у меня нет сильного аргумента против того, чтобы не проверять файлы, я собираюсь следовать советам не выполнять проверку. –

3

Как я уже говорил ранее.

I would rather discard the changes on AssemblyInfo.* files than check them into the source control.

В моем случае я использую 1.$(date:yy).$(date:MMdd)$(rev:.r) как формат номер сборки

enter image description here

Так что я никогда не буду читать обратно версию из а-AssemblyInfo.* файлов, так что точка сохранения этой информации ? Числовой формат

Строить будет генерировать версию снова независимо от значения, хранящееся в AssemblyInfo.*

Если вы хотите синхронизировать исходный код с конкретной версией, которую вы могли бы использовать тот же формат номер сборки для обозначения исходного кода.

enter image description here

Смежные вопросы