Используя Azure DevOps, получить список коммитов от GitHub, чтобы перейти на Sentry как часть релиза? - PullRequest
6 голосов
/ 28 февраля 2020

Я использую Azure конвейеры для сборки и выпуска своего программного обеспечения через интеграцию с GitHub. В рамках мониторинга я использую Sentry для записи исключений и т. Д. c.

Я хочу использовать функцию Sentry «Suspect Commits» (поэтому она может указывать на коммиты, которые, вероятно, вызвали конкретный c вопрос). Чтобы это работало, мне нужно отправить Sentry релиз (просто версию, связанную с конкретным c проектом) со списком связанных с ним коммитов.

Я прочитал этот пост:

Azure Интеграция DevOps в Sentry: Ассоциированные коммиты

И этот на GitHub:

https://github.com/getsentry/sentry/issues/11127

И хотя у обоих есть (очень разные) подходы к получению списка коммитов, они предполагают, что один использует функцию репозиториев Azure DevOps. У меня нет репозиториев на моем экземпляре DevOps, поэтому, хотя они и полезны, они не помогают мне напрямую.

Короче говоря - мне нужно перечислить все коммиты на GitHub, связанные с указанным релизом c на Azure DevOps, чтобы я мог отправить их в Sentry API.

Кто-нибудь делал это? Как я могу этого достичь? Я что-то упускаю из виду?

1 Ответ

0 голосов
/ 03 марта 2020

Как я уже упоминал в комментарии, API get-changes , который использовался в этом билете, не подходит для конвейера сборки, у которого есть источник репозитория github .

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

GET https://dev.azure.com/{org name}/{project name}/_traceability/runview/changes?currentRunId={build id}&__rt=fps&__ver=2

В большинстве случаев вы можете отловить некоторые записи из F12, когда вы не найдете пути к документам, которые мы публикуем c. Выше api можно получить из F12, пока вы нажимаете на ссылку Changes на странице Build Summary:

enter image description here


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

$token = "{PAT token}"

$url="https://dev.azure.com/{org name}/{project name}/_traceability/runview/changes?currentRunId={build id}&__rt=fps&__ver=2"

$token = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($token)"))

$response = Invoke-RestMethod -Uri $url -Headers @{Authorization = "Basic $token"} -Method Get

Write-Host "results = $($response.fps.dataProviders.data.'ms.vss-traceability-web.traceability-run-changes-data-provider'.artifactsData.data.id | ConvertTo-Json -Depth 100)"

enter image description here


В конвейере выпуска мы предоставляем одну встроенную переменную среды, в которую вы можете напрямую получить соответствующий запущенный идентификатор сборки: $(Build.Buildid). И вы можете вставить это в api, чтобы идентификатор сборки можно было получать автоматически во время процесса CI + CD.


Обновление от 3/4/2020:

Основываясь на скриншоте, который вы предоставили в нашем обсуждении, ваша структура данных предназначена для git репо (, не знаю почему, будет копать это ):

Пожалуйста, перенесите конвейер с YAML. Затем запустите его и напишите коммиты, используя сценарии, которые я опубликовал выше Вы увидите данные коммитов по результатам YAML.

...