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

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

Posts Tagged ‘powershell’

Восстановление Git репозиториев в Azure DevOps через Rest Api и PowerShell

Posted by Shamrai Alexander на 20 февраля, 2020

Удаление репозиториев Git в Azure DevOps не приводит к их полному удалению из командного проекта. Удаленные репозитории перемещаются в корзину проекта, но пока нет никаких инструментов для работы с ней. Однако можно воспользоваться функциями Rest Api для того, чтобы:

  1. Узнать какие репозитории были удалены
  2. Восстановить нужные репозитории
  3. Очистить корзину окончательно

Для работы с Rest Api воспользуемся PowerShell, который позволяет довольно быстро выполнять вызовы и разбирать их результаты. Перед выполнением запросов необходимо знать имя командного проекта и имя организации, а также необходимо сгенерировать Personal Access Token. Эти параметры нужно будет установить в скриптах ниже.

Перед тем как выполнить восстановление репозитория, нужно убедиться, что он находится в корзине проекта. Для этого можно воспользоваться следующим вызовом: Get Recycle Bin Repositories. Далее в результирующем списке можно выполнить поиск необходимого репозитория. Пример просмотра корзины (скрипт GetRecycleBinRepositories.ps1):

$listDeletedRepo = «https://dev.azure.com/$org/$teamProject/_apis/git/recycleBin/repositories?api-version=5.1-preview.1″

$resultDeletedRepo = Invoke-RestMethod -Uri $listDeletedRepo -Method Get -ContentType «application/json» -Headers @{Authorization=(«Basic {0}» -f $base64AuthInfo)}

foreach ($repo in $resultDeletedRepo.value)

{

    Write-Host «=============================================»

    Write-Host «Id :» $repo.id

    Write-Host «Name:» $repo.name

}

Для восстановления репозитория нужно выполнить следующую команду: Restore Repository From Recycle Bin. В этой функции нужно становить признак deleted в значение false. Пример восстановления репозитория (скрипт RestoreRepositoryFromRecycleBin.ps1):

$restoreRepo = «https://dev.azure.com/$org/$teamProject/_apis/git/recycleBin/repositories/» + $repoId + «?api-version=5.1-preview.1»

$restoreBody = «{deleted:false}»

$resultrestoredRepo = Invoke-RestMethod -Uri $restoreRepo -Method Patch -ContentType «application/json» -Headers @{Authorization=(«Basic {0}» -f $base64AuthInfo)} -Body $restoreBody

Write-Host $resultrestoredRepo

Если репозиторий не нужен, то его можно удалить окончательно через: Delete Repository From Recycle Bin. При этом здесь нужно передать идентификатор репозитория, который можно узнать через функцию Get Recycle Bin Repositories. Пример удаления репозитория (скрипт для очистки корзины DeleteRepositoriesFromRecycleBin.ps1)

$hardDeleteRepo = «https://dev.azure.com/$org/$teamProject/_apis/git/recycleBin/repositories/» + $repo.id + «?api-version=5.1-preview.1»

Invoke-RestMethod -Uri $hardDeleteRepo -Method Delete -ContentType «application/json» -Headers @{Authorization=(«Basic {0}» -f $base64AuthInfo)}

Write-Host «Deleted repo:» $repo.name

Posted in azure, devops, Microsoft | Отмечено: , , , | Leave a Comment »

Автоматизированное создание GIT запросов на включение кода через сборки Azure DevOps

Posted by Shamrai Alexander на 27 декабря, 2019

Часто командам разработки на основе типовых моделей ветвлений необходимо выполнять рутинные слияния изменений из общего интеграционного потока (master) в свои командные ветви для того, чтобы получить изменения от других команд и понять их влияние на текущую работу. Выполнять это лучше чаще, чтоб раньше узнать о возможных проблемах. Выполнять это можно вручную, что довольно часто игнорируется. А можно этот шаг автоматизировать с помощью вызовов Rest API через PowerShell. При этом достаточно создать один запрос на включение изменений, и он будет периодически пополняться новыми изменениями при каждом новом комите в общий интеграционный поток. Создавать запрос на включение изменений через сборки Azure DevOps можно несколькими путями:

  1. Периодически на основе расписания запуска сборки.
  2. На основе непрерывной интеграции, т.е. каждый новый комит в общий интеграционный поток создает новый запрос на включение изменений в поток разработки команды.

Для создания сборки на основе расписаний необходимо выполнить следующие шаги:

  • Проверить, что пользователь выполнения сборок имеет доступ для создания запросов на изменение через разрешение Contribute to pull requests.

Рисунок 1. Разрешение на работу с запросами на включение изменений

  • Создать новое определение сборки. В моем случае, через классический редактор.

Рисунок 2. Выбор классического редактора

  • Указать репозиторий и ветвь, в которую будут создаваться запросы на включение кода из master.

Рисунок 3. Указание репозитория и ветви

  • Выбрать пустой набор шагов:

Рисунок 4. Определение сборки без шагов

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

Рисунок 5. Отключение скачивания кода

  • Дать возможность заданиям сборки получать ключ доступа к сервису.

Рисунок 6. Разрешение для получения ключа доступа

  • Указать необходимый период выполнения задания.

Рисунок 7. Установка расписания выполнения

  • Добавить только один шаг PowerShell с типом Inline.

Рисунок 8. Задача PowerShell

Сам же скрипт будет выполнять следующие шаги:

  • Зафиксировать необходимые параметры из предопределенных переменных сборки (ключ доступа, адрес организации, имя проекта, имя репозитория и ветви для запроса на включение изменений). Источником изменений будет master.

$token = «$(System.AccessToken)«

$branchTarget = «$(Build.SourceBranch)«

$branchSource = «refs/heads/master»

$branchTragetPath = $branchTarget -replace «refs/heads/», «»

$teamProject = «$(System.TeamProject)«

$repoName = «$(Build.Repository.Name)«

$orgUrl = «$(System.CollectionUri)«

  • Проверка, есть ли новые комиты в мастере через запрос Stats – Get, результат которого содержит свойство behindCount.

$uriBranchStatus = «$orgUrl/$teamProject/_apis/git/repositories/$repoName/stats/branches?name=$branchTragetPath&api-version=5.1″

resultStatus = Invoke-RestMethod -Uri $uriBranchStatus -Method Get -ContentType «application/json» -Headers @{Authorization=(«Basic {0}» -f $base64AuthInfo)}

if ($resultStatus.behindCount -eq 0)

{

    Write-Host «Current branch contains last changes from master»

    Return

}

  • Проверка, существует ли уже активный запрос на включение изменений через метод Pull Requests — Get Pull Requests. Метод возвращает массив соответствующих поисковому запросу запросов на включение кода. Если массив пустой, то и нет запросов на включение кода.

$uriCheckActivePR = «$orgUrl/$teamProject/_apis/git/repositories/$repoName/pullrequests?searchCriteria.targetRefName=$branchTarget&searchCriteria.sourceRefName=$branchSource&api-version=5.1″

$resultActivePR = Invoke-RestMethod -Uri $uriCheckActivePR -Method Get -ContentType «application/json» -Headers @{Authorization=(«Basic {0}» -f $base64AuthInfo)}

if ($resultActivePR.count -gt 0)

{

    Write-Host «PR exists already»

    Return

}

  • Создать запрос на включение изменений через метод Pull Requests – Create, в тело которого передается информация о источнике и цели запроса на включение кода.

$uriCreatePR = «$orgUrl/$teamProject/_apis/git/repositories/$repoName/pullrequests?api-version=5.1″

$bodyCreatePR = «{sourceRefName:’$branchSource‘,targetRefName:’$branchTarget‘,title:’Sync changes from $branchSource‘}»

result = Invoke-RestMethod -Uri $uriCreatePR -Method Post -ContentType «application/json» -Headers @{Authorization=(«Basic {0}» -f $base64AuthInfo)} -Body $bodyCreatePR

Write-Host «Created PR» $result.pullRequestId

Результирующий шаг в сборке:

Рисунок 9. Скрипт в сборке

Содержимое скрипта можно посмотреть здесь: https://github.com/ashamrai/AzureDevOpsExtensions/blob/master/CustomPSTasks/CreatePRBuildTask.ps1

Posted in azure, devops, Microsoft | Отмечено: , , , | Leave a Comment »

Автоматическое обновление целевой даты исправления ошибки на основе Azure DevOps CLI

Posted by Shamrai Alexander на 12 ноября, 2019

Часто в проектах возникает потребность устанавливать определенные сроки для исправления ошибок определенного приоритета. Т.к. в процессах Azure DevOps отсутствует возможность использовать вычисляемые поля, то решать данную задачу приходится с помощью не-коробочных возможностей (например, Excel или отдельно разработать утилиту на основе Rest API). Однако использование Azure DevOps CLI позволяет значительно сэкономить время, необходимое на решение подобного вопроса.

Попробуем реализовать схожую задачу. Для этого нам понадобится следующее:

  1. PowerShell
  2. Azure DevOps CLI
  3. Personal Access Token
  4. Адрес организации Azure DevOps и наименование проекта
  5. Подготовленный запрос на основе WIQL, которые отберет необходимые рабочие элементы и поля, на основе которых будет выполнять вычисление. Например, можно сразу отбирать дату создания и на ее основе устанавливать целевую дату.

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

  • Установить значения по умолчанию для адреса организации Azure DevOps и наименования проекта. Это позволит не использовать эти параметры в каждой следующей команде:

az devops configure -d organization=$azdOrg project=$azdProject

  • Выполнить подготовленный ранее запрос. Команда вернет ответ в json формате, поэтому результат нужно конвертировать:

$workItems = (az boards query —wiql «$queryWiql« | ConvertFrom-Json)

  • Обновить необходимое поле для обнаруженный рабочих элементов:

az boards work-item update —id $workItem.id —fields «Microsoft.VSTS.Scheduling.DueDate=$targetDateStr» —discussion «Updated by CLI»

Вот и все. Полный пример можно посмотреть здесь: https://github.com/ashamrai/AzureDevOpsExtensions/blob/master/CustomPSTasks/UpdateBugTargetDate.ps1

Posted in azure, devops, Microsoft | Отмечено: , , | Leave a Comment »

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