Могу ли я установить политику безопасности и / или политики по умолчанию в Visual Studio Team Services (Visual Studio Online)?

Мы используем Visual Studio Team Services для нашего git-сервера. Каждый проект VSTS содержит один или несколько репозиториев git. У нас есть соглашение о соблюдении master а также develop ветви заблокированы, но другие ветви остаются без ограничений.

Я хотел бы иметь возможность применять наши стандартные правила на уровне проекта и иметь их по умолчанию для всех репозиториев в них:

  • master а также develop должно быть их безопасность отрицать Force Push
  • master филиал требует запроса на извлечение через политику проверки кода

Пока единственная опция, которую я нашел, - это вручную установить эти репозитории через веб-интерфейс (даже не API!). У нас есть по крайней мере 200+ репозиториев, и мы бы хотели избежать ручной настройки каждого репо и ветвления один за другим.

Как установить безопасность кода по умолчанию и политики кода по имени ветки? Или любым другим способом, кроме как вручную?

1 ответ

  • Для настройки политик ветвления с минимальным количеством проверяющих для нескольких репозиториев git в командном проекте (на уровне проекта) вы можете использовать REST API. Подробные шаги, как показано ниже:

1. Получить все репозитории git для командного проекта.

GET https://account.visualstudio.com/DefaultCollection/ProjectName/_apis/git/repositories?api-version=1.0

Затем сохраните каждый идентификатор и имя git-репо из выходных данных.

2. Зациклите репозитории, которые вы получили в шаге 1 в своем коде, по идентификатору репо, и создайте политику веток для каждой основной ветки (предположим, что минимальное количество рецензентов здесь равно 2).

POST https://account.visualstudio.com/DefaultCollection/ProjectName/_apis/policy/configurations?api-version=2.0-preview

Применение / JSON:

{
  "isEnabled": true,
  "isBlocking": true,
  "type": {
    "id": "fa4e907d-c16b-4a4c-9dfa-4906e5d171dd"
  },
  "settings": {
                "minimumApproverCount": 2,
                "creatorVoteCounts": false,
                "allowDownvotes": false,
                "scope": [
                    {
                        "refName": "refs/heads/master",
                        "matchKind": "Exact",
                        "repositoryId": "{repo id}"
                    }
                ]
  }
}

Чтобы создать скрипт безопасности репозитория и ветки, вы можете использовать tfssecurity.exeили новый REST API разрешений или Azure CLI. Все подробности в следующем сообщении в блоге:

Для определенных веток добавьте /refs^heads^master/ в конце токена.

Выдержка

Если вы в прошлом копались во внутренностях безопасности Azure DevOps, вы узнали, что определенные разрешения предоставляются отдельным лицам или группам и связаны с токеном. Этот токен обычно создается из корневого объекта и набора идентификаторов GUID. Например, это токен для определенного репозитория Git:

repoV2/daec401a-49b6-4758-adb5-3f65fd3264e3/f59f38e0-e8c4-45d5-8dee-0d20e7ada1b7
^      ^                                    ^
|      |                                    |
|      |                                    -- The Git Repository
|      -- The Team Project Guid
|
-- The root object (Repositories)

Самый простой способ найти эти детали, который я знаю, - это записать веб-запрос, сделанный при изменении разрешения:

Вы можете использовать инструменты веб-разработчика в своем любимом браузере, чтобы найти нужный токен. Как только вы это поймете, легко найти токен для токена "Все репозитории в командном проекте". Просто удалите GUID репозитория Git в конце:

repoV2/daec401a-49b6-4758-adb5-3f65fd3264e3b7/
^      ^                                    
|      |                                    
|      -- The Team Project Guid
|
-- The root object (Repositories)

И, используя те же рассуждения, чтобы получить токен для токена "Все репозитории в коллекции / организации проекта". Просто снимите GUID командного проекта в конце:

repoV2/
^                                          
|
-- The root object (Repositories)

И теперь, когда у нас есть этот токен, мы можем использовать tfssecurity для установки разрешений git на уровне организации:

tfssecurity /a+ "Git Repositories" repoV2/ "PullRequestBypassPolicy" adm: ALLOW /collection:https://dev.azure.com/org
            ^   ^                  ^       ^                         ^    ^
            |   |                  |       |                         |    -- Allow or Deny the permission 
            |   |                  |       |                         -- The Group (in this case "Project Collection Administrators")
            |   |                  |       -- The Permission we want to set
            |   |                  -- The Token we found above
            |   -- The Secuity Namespace
            -- Add  (a+) or Remove (a-) this permission

И, как видно ниже, этот трюк действительно работает:).

Вы можете использовать ту же технику для защиты веток. Токен ветки использует токен Репозитория в качестве основы и добавляет к нему ветку. Потому что/ является разделителем токенов, ссылка на ветвь экранируется путем замены / с участием ^. Таким образомrefs/heads/master становится: refs^heads^master:

repoV2/daec401a-49b6-4758-adb5-3f65fd3264e3/f59f38e0-e8c4-45d5-8dee-0d20e7ada1b7/refs^heads^master/
^      ^                                    ^                                    ^
|      |                                    |                                    |
|      |                                    |                                    -- The branch
|      |                                    -- The Git Repository
|      -- The Team Project Guid
|
-- The root object (Repositories)

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

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

Просто перейдите в "Настройки проекта" => "Политики перекрестного репо".

Единственное предостережение: это недавнее изменение, которое в настоящее время будет доступно только в облачной службе Azure Devops, а не в развертываниях сервера Azure Devops. Так что, если вы используете серверную версию, вам может потребоваться некоторое время подождать.

Вы можете сослаться на этот URL: https://docs.microsoft.com/en-us/azure/devops/release-notes/2019/repos/sprint-160-update

Другие вопросы по тегам