Заметки консультанта

Шамрай Александр Владимирович

Archive for 09.04.2019

Azure DevOps Services Rest Api. 18. Создание и клонирование определения сборки

Posted by Shamrai Alexander на Апрель 9, 2019

В рамках данной статьи мы рассмотрим созданием и клонирование определений сборки для yaml формата и графического мастера. В общем их структура одинаковая, но они отличаются только параметром, который характеризует шаги выполнения сборки. В yaml формате это ссылка на соответствующий файл в версионном контроле, а для графического мастера – детальное определение фаз и шагов выполнения. Основным хранилищем версионного контроля будет выступать внутренний GIT. Для управления сборками используется клиент BuildHttpClient.

Создание определения сборки

Создание определения сборки мы рассмотрим на примере yaml формата, т.к. он проще для реализации. В данном случае можно создать типовой файл с описанием его шагов, а такие элементы как путь к решению, конфигурация и т.д. вынести в параметры и определять в процессе создания. Перед созданием сборки необходимо сформировать yaml файл. С нуля его можно написать, но проще подсмотреть в существующей сборки. Увидеть yaml шаги можно следующим образом:

  1. Открыть на редактирование существующее определение сборки.
  2. Выбрать фазу выполнения на агенте и нажать на ссылку View YAML:

Для определения сборки используется класс BuildDefinition, который содержит следующие основные атрибуты:

  • Path – путь или каталог, в котором будет храниться определение сборки.
  • Name – наименование определения сборки.
  • Queue – пул через который будет запускаться новая сборка. Определяется через класс AgentPoolQueue, в котором указывается наименование пула.
  • Process – описание процесса выполнения шагов. Для yaml формата используется класс YamlProcess, в котором через атрибут YamlFilename указывается путь к yaml файлу в версионном хранилище.
  • Repository – описывает используемое хранилище исходного кода. Описывается классом BuildRepository, который включает в себя:
    • Url – url для клонирования репозитория. Посмотреть его можно на основе следующих шагов: Clone the repo to your computer
    • Name – имя репозитория
    • Type – тип репозитория, который описывается через статический класс RepositoryTypes.
  • Variables – переменные, которыми определяем путь к решению, конфигурацию и платформу сборки.

Далее запускается метод CreateDefinitionAsync, в который передается наименование командного проекта и сформированное определение сборки. Пример создания:

BuildDefinition newBuild = new BuildDefinition();
newBuild.Path = BuildPath;

newBuild.Name = BuildName;

newBuild.Queue = new AgentPoolQueue() { Name = «Hosted VS2017» };

YamlProcess yamlProcess = new YamlProcess();

yamlProcess.YamlFilename = «<yaml file>»;

newBuild.Process = yamlProcess;

newBuild.Repository = new BuildRepository();

newBuild.Repository.Url = new Uri(String.Format(GitRepoFormat, TeamProjectName, GitRepoName));

newBuild.Repository.Name = GitRepoName;

newBuild.Repository.DefaultBranch = RepoBranch;

newBuild.Repository.Type = RepositoryTypes.TfsGit;

newBuild.Variables.Add(«BuildConfiguration», new BuildDefinitionVariable { AllowOverride = false, IsSecret = false, Value = «Debug» });

newBuild.Variables.Add(«BuildPlatform», new BuildDefinitionVariable { AllowOverride = false, IsSecret = false, Value = «Any CPU» });

newBuild.Variables.Add(«Parameters.solution», new BuildDefinitionVariable { AllowOverride = false, IsSecret = false, Value = SlnPath });

newBuild = BuildClient.CreateDefinitionAsync(newBuild, TeamProjectName).Result;

Клонирование определения сборки

Клонирование сборки рассмотрим на примере определений в графическом мастере. Т.к. для создания данных определений необходимо описывать процесс через класс DesignerProcess, что может быть длительным набором действий. Проще создать типовое определение сборки и в дальнейшем выполнять ее клонирование с подменой необходимых параметров. Т.е. выполняться будут следующие шаги:

  1. Получение существующего определения сборки.
  2. Обновление необходимых параметров.
  3. Создание новой сборки.

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

Далее необходимо изменить необходимые параметры в полученной сборке, например:

  • Repository – описывает используемое хранилище исходного кода. Описывается классом BuildRepository, который включает в себя:
    • Url – url для клонирования репозитория. Посмотреть его можно на основе следующих шагов: Clone the repo to your computer
    • Name – имя репозитория
    • DefaultBranch – наименование ветви репозитория.
  • Path – путь к новому определению сборки.
  • Name – наименование нового определения сборки.

Далее вызывается метод CreateDefinitionAsync:

var bld = BuildClient.GetDefinitionAsync(TeamProjectName, SourceBuildId).Result;
var clonedBuild = bld;

clonedBuild.Repository.Url = new Uri(String.Format(GitRepoFormat, TeamProjectName, GitRepoName));

clonedBuild.Repository.Name = GitRepoName;

clonedBuild.Repository.Id = null;

if (NewBranch != null) clonedBuild.Repository.DefaultBranch = NewBranch;

clonedBuild.Path = NewPath;

clonedBuild.Name = NewName;

if (NewProjectPath != null && clonedBuild.ProcessParameters.Inputs.Count == 1)

clonedBuild.ProcessParameters.Inputs[0].DefaultValue = NewProjectPath;

clonedBuild = BuildClient.CreateDefinitionAsync(clonedBuild, TeamProjectName).Result;

Пример тестового приложения можно посмотреть здесь:

https://github.com/ashamrai/TFRestApi/tree/master/18.TFRestApiAppCreateCloneBuild

Posted in Microsoft, Team Foundation Server, Visual Studio, visual studio team services | Отмечено: , , , , | Leave a Comment »

 
%d такие блоггеры, как: