resources.webhooks.webhook 정의
웹후크 리소스를 사용하면 파이프라인을 외부 서비스와 통합하여 워크플로를 자동화할 수 있습니다.
webhooks:
- webhook: string # Required as first property. Name of the webhook.
connection: string # Required. Name of the connection. In case of offline webhook this will be the type of Incoming Webhook otherwise it will be the type of the webhook extension.
type: string # Name of the webhook extension. Leave this empty if it is an offline webhook.
filters: [ filter ] # List of trigger filters.
이 정의를 참조하는 정의: resources.webhooks
속성
webhook 문자열. 첫 번째 속성으로 필요합니다.
웹후크의 이름입니다. 허용되는 값: [-_A-Za-z0-9]*.
connection 문자열. 필수 사항입니다.
연결의 이름입니다. 오프라인 웹후크의 경우 들어오는 웹후크의 형식이 됩니다. 그렇지 않으면 웹후크 확장의 형식이 됩니다.
type 문자열.
웹후크 확장의 이름입니다. 오프라인 웹후크인 경우 비워 둡니다.
filtersresources.webhooks.webhook.filters.
트리거 필터 목록입니다.
예제
기본 예제
파이프라인을 다음과 같이 정의할 수 있습니다.
resources:
webhooks:
- webhook: WebHook
connection: IncomingWH
steps:
- script: echo ${{ parameters.WebHook.resource.message.title }}
웹후크를 사용하여 파이프라인을 트리거하려면 에 요청https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<webhook_connection_name>?api-version=6.0-preview해야 POST 합니다. 이 엔드포인트는 공개적으로 사용할 수 있으며 권한 부여가 필요하지 않습니다. 요청에는 다음 본문이 있어야 합니다.
{
"resource": {
"message": {
"title": "Hello, world!",
"subtitle": "I'm using WebHooks!"
}
}
}
웹후크의 요청 본문에서 데이터에 액세스할 때 잘못된 YAML이 발생할 수 있다는 점을 염두에 두어야 합니다. 예를 들어 이전 파이프라인에서 단계가 를 읽고 - script: echo ${{ parameters.WebHook.resource.message }}웹후크를 통해 파이프라인을 트리거하는 경우 파이프라인이 실행되지 않습니다. 다음 JSON을 포함하는 을 message로 바꾸는 ${{ parameters.WebHook.resource.message.title }} 과정에서 생성된 YAML이 잘못되기 때문입니다.
{
"title": "Hello, world!",
"subtitle": "I'm using WebHooks!"
}
생성된 YAML이 유효하지 않으므로 파이프라인 실행이 응답에 큐에 대기되지 않습니다.
권한 없는 파이프라인 실행 방지
웹후크를 사용하면 모든 사용자가 organization 및 웹후크 서비스 연결의 이름을 알고 있는 한 파이프라인을 트리거할 수 있습니다.
들어오는 웹후크 서비스 연결을 만들 때 비밀을 정의하여 권한이 없는 파이프라인 실행을 방지할 수 있습니다. 웹후크 본문의 SHA-1 체크섬을 포함하는 HTTP 헤더의 이름도 지정해야 합니다.
들어오는 웹후크 REST API 호출에 권한이 부여되었는지 확인하기 위해 Azure Pipelines는 비밀을 키로 사용하여 요청 본문의 SHA-1 체크섬을 계산합니다. 그런 다음 요청 헤더에 전달된 체크섬과 비교합니다. 이렇게 하면 호출자가 비밀을 알고 있음을 증명합니다.
예제를 살펴보겠습니다. 라는 IncomingWH들어오는 웹후크 서비스 연결을 구성했다고 가정합니다. 비밀이 secret이고 체크섬이 라는 X-WH-ChecksumHTTP 헤더로 전송되도록 지정했습니다. 웹후크 리소스를 정의하는 파이프라인이 있다고 상상해 보십시오.
다음 요청 본문을 사용하여 파이프라인을 트리거한다고 가정해 봅시다.
{"resource":{"message":{"title":"Hello, world!","subtitle":"I'm using WebHooks!"}}}
이렇게 하려면 에 요청을 https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/IncomingWH?api-version=6.0-preview 하고 값750D33212D3AD4932CC390819050734831A0A94F이 인 POST 헤더를 X-WH-Checksum 추가해야 합니다. 사용자 이름 & 암호 또는 다른 유형의 인증 정보를 지정할 필요가 없습니다.
Azure Pipelines는 키로 사용하여 본문의 SHA-1 체크섬을 secret 독립적으로 계산하고 동일한 750D33212D3AD4932CC390819050734831A0A94F 값을 생성합니다. 값이 일치하므로 호출에 권한이 부여되고 파이프라인 큐가 진행됩니다.
헤더의 X-WH-Checksum 값을 의사 코드 SHA1(secret).ComputeHash(requestBody)로 계산합니다. 를 사용할 수 있습니다. 이 목적을 위한 NET의 클래스입니다 System.Security.Cryptography.HMACSHA1 .
새 줄 또는 공백으로 인한 유효성 검사 실패를 방지하려면 본문을 최소화된 형식으로 보내는 것이 좋습니다. 즉, 보내기
{"resource":{"message":{"title":"Hello, world!","subtitle":"I'm using WebHooks!"}}}
(예:
{
"resource": {
"message": {
"title": "Hello, world!",
"subtitle": "I'm using WebHooks!"
}
}
}
위의 두 JSON 개체가 동일한 개체를 나타내더라도 다른 SHA-1 체크섬을 생성합니다. 이는 SHA-1이 문자열 표현에서 계산되기 때문입니다. 이는 서로 다릅니다.