기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 에서 웹후크 사용 AWS CodeBuild
AWS CodeBuild 는 GitHub, GitHub Enterprise Server, GitLab, GitLab 자체 관리형 및 Bitbucket과의 웹후크 통합을 지원합니다.
**Topics**
+ [에서 웹후크를 사용하는 모범 사례 AWS CodeBuild](#webhook-best-practices)
+ [Bitbucket Webhook 이벤트](bitbucket-webhook.md)
+ [GitHub 글로벌 및 조직 웹후크](github-global-organization-webhook.md)
+ [GitHub 수동 웹후크](github-manual-webhook.md)
+ [GitHub Webhook 이벤트](github-webhook.md)
+ [GitLab 그룹 웹후크](gitlab-group-webhook.md)
+ [GitLab 수동 웹후크](gitlab-manual-webhook.md)
+ [GitLab 웹후크 이벤트](gitlab-webhook.md)
+ [Buildkite 수동 웹후크](buildkite-manual-webhook.md)
+ [풀 요청 설명 승인](pull-request-build-policy.md)
## 에서 웹후크를 사용하는 모범 사례 AWS CodeBuild
퍼블릭 리포지토리를 사용하여 webhook를 설정하는 프로젝트의 경우 다음 옵션을 권장합니다.
`ACTOR_ACCOUNT_ID` 필터 설정
프로젝트의 webhook 필터 그룹에 `ACTOR_ACCOUNT_ID` 필터를 추가하여 빌드를 트리거할 수 있는 사용자를 지정합니다. CodeBuild로 전달되는 모든 webhook 이벤트는 행위자의 식별자를 지정하는 발신자 정보와 함께 제공됩니다. CodeBuild는 필터에 제공된 정규 표현식 패턴을 기준으로 webhook를 필터링합니다. 이 필터를 사용하여 빌드를 트리거할 수 있는 특정 사용자를 지정할 수 있습니다. 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 및 [Bitbucket Webhook 이벤트](bitbucket-webhook.md) 섹션을 참조하세요.
`FILE_PATH` 필터 설정
프로젝트의 webhook 필터 그룹에 `FILE_PATH` 필터를 추가하여 변경 시 빌드를 트리거할 수 있는 파일을 포함하거나 제외합니다. 예를 들어 `excludeMatchedPattern` 속성과 함께 `^buildspec.yml$`과 같은 정규 표현식 패턴을 사용하여 `buildspec.yml` 파일 변경에 대한 빌드 요청을 거부할 수 있습니다. 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 및 [Bitbucket Webhook 이벤트](bitbucket-webhook.md) 섹션을 참조하세요.
빌드 IAM 역할의 권한 범위 좁히기
webhook로 트리거되는 빌드는 프로젝트에 지정된 IAM 서비스 역할을 사용합니다. 서비스 역할의 권한을 빌드를 실행하는 데 필요한 최소 권한 세트로 설정하는 것이 좋습니다. 예를 들어 테스트 및 배포 시나리오에서는 테스트용 프로젝트 하나와 배포용 프로젝트 하나를 생성합니다. 테스트 프로젝트는 리포지토리의 webhook 빌드를 수락하지만 리소스에 대한 쓰기 권한은 제공하지 않습니다. 배포 프로젝트는 리소스에 대한 쓰기 권한을 제공하고 webhook 필터는 신뢰할 수 있는 사용자만 빌드를 트리거할 수 있도록 구성됩니다.
인라인 또는 Amazon S3 저장 buildspec 사용
프로젝트 내에서 buildspec 인라인을 정의하거나 Amazon S3 버킷에 buildspec 파일을 저장하는 경우, buildspec 파일은 프로젝트 소유자만 볼 수 있습니다. 이렇게 하면 풀 요청이 buildspec 파일의 코드를 변경하여 원치 않는 빌드를 트리거하는 것을 방지할 수 있습니다. 자세한 내용은 CodeBuild API 참조의 [ProjectSource.buildspec](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectSource.html#CodeBuild-Type-ProjectSource-buildspec)을 참조하세요.**
# Bitbucket Webhook 이벤트
Webhook 필터 그룹을 사용하여 어느 Bitbucket Webhook 이벤트가 빌드를 트리거할지 지정할 수 있습니다. 예를 들어 특정 분기가 변경된 경우에만 빌드가 트리거되도록 지정할 수 있습니다.
하나 이상의 웹후크 필터 그룹을 생성하여 어느 웹후크 이벤트가 빌드를 트리거할지 지정할 수 있습니다. 필터 그룹이 true로 평가(그룹 내 모든 필터가 true로 평가)되면 빌드가 트리거됩니다. 필터 그룹을 생성할 때 다음을 지정합니다.
**이벤트**
Bitbucket의 경우 다음 이벤트 중 하나 이상을 선택할 수 있습니다.
+ `PUSH`
+ `PULL_REQUEST_CREATED`
+ `PULL_REQUEST_UPDATED`
+ `PULL_REQUEST_MERGED`
+ `PULL_REQUEST_CLOSED`
webhook의 이벤트 유형은 `X-Event-Key` 필드의 헤더에 있습니다. 다음 표에서는 `X-Event-Key` 헤더 값이 이벤트 유형에 매핑되는 방법을 보여 줍니다.
`PULL_REQUEST_MERGED` 이벤트 유형을 사용하는 webhook 필터 그룹을 생성할 경우 Bitbucket webhook 설정의 `merged` 이벤트를 활성화해야 합니다. `PULL_REQUEST_CLOSED` 이벤트 유형을 사용하는 웹후크 필터 그룹을 생성할 경우 Bitbucket 웹후크 설정에서 `declined` 이벤트를 활성화해야 합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/bitbucket-webhook.html)
`PULL_REQUEST_MERGED`의 경우 풀 요청이 스쿼시 전략에 병합되고 풀 요청 분기가 닫히면 원래의 풀 요청 커밋은 더 이상 존재하지 않게 됩니다. 이 경우 `CODEBUILD_WEBHOOK_MERGE_COMMIT` 환경 변수에는 스쿼시된 병합 커밋의 식별자가 포함됩니다.
**하나 이상의 선택적 필터**
정규식을 사용하여 필터를 지정합니다. 이벤트가 빌드를 트리거하려면 연결된 그룹 내의 필터가 모두 true로 평가되어야 합니다.
`ACTOR_ACCOUNT_ID`(콘솔의 `ACTOR_ID`)
Bitbucket 계정 ID가 정규식 패턴과 일치하면 Webhook 이벤트가 빌드를 트리거합니다. Webhook 필터 페이로드에 있는 `actor` 객체의 `account_id` 속성에 이 값이 표시됩니다.
`HEAD_REF`
헤드 참조가 정규식 패턴(예: `refs/heads/branch-name` 및 `refs/tags/tag-name`)과 일치하면 webhook 이벤트가 빌드를 트리거합니다. `HEAD_REF` 필터가 브랜치나 태그의 Git 참조 이름을 평가합니다. Webhook 페이로드의 `push` 객체에 있는 `new` 객체의 `name` 필드에 브랜치 또는 태그 이름이 표시됩니다. pull 요청 이벤트의 경우 webhook 페이로드의 `source` 객체에 있는 `branch` 객체의 `name` 필드에 브랜치 이름이 표시됩니다.
`BASE_REF`
베이스 참조가 정규식 패턴과 일치하면 webhook 이벤트가 빌드를 트리거합니다. `BASE_REF` 필터는 풀 요청 이벤트에서만 작동합니다(예: `refs/heads/branch-name`). `BASE_REF` 필터가 브랜치의 Git 참조 이름을 평가합니다. Webhook 페이로드의 `destination` 객체에 있는 `branch` 객체의 `name` 필드에 브랜치 이름이 표시됩니다.
`FILE_PATH`
변경된 파일의 경로가 정규식 패턴과 일치하면 webhook가 빌드를 트리거합니다.
`COMMIT_MESSAGE`
헤드 커밋 메시지가 정규식 패턴과 일치하면 webhook가 빌드를 트리거합니다.
`WORKFLOW_NAME`
워크플로 이름이 정규식 패턴과 일치하면 웹후크가 빌드를 트리거합니다.
**참고**
Bitbucket 리포지토리의 webhook 설정에서 webhook 페이로드를 찾을 수 있습니다.
**Topics**
+ [Bitbucket Webhook 이벤트 필터링(콘솔)](bitbucket-webhook-events-console.md)
+ [Bitbucket Webhook 이벤트 필터링(SDK)](bitbucket-webhook-events-sdk.md)
+ [Bitbucket Webhook 이벤트 필터링(CloudFormation)](bitbucket-webhook-events-cfn.md)
# Bitbucket Webhook 이벤트 필터링(콘솔)
AWS Management Console 를 사용하여 웹후크 이벤트를 필터링하려면:
1. 프로젝트를 생성할 때 **코드 변경이 이 리포지토리로 푸시될 때마다 다시 빌드**를 선택합니다.
1. **이벤트 유형**에서 하나 이상의 이벤트를 선택합니다.
1. 이벤트가 빌드를 트리거할 때를 필터링하려면 **Start a build under these conditions(다음 조건에서 빌드를 시작)**에서 하나 이상의 선택적 필터를 추가합니다.
1. 이벤트가 트리거되지 않을 때를 필터링하려면 **Don't start a build under these conditions(다음 조건에서 빌드를 시작하지 않음)**에서 하나 이상의 선택적 필터를 추가합니다.
1. **Add filter group(필터 그룹 추가)**를 선택하여 다른 필터 그룹을 추가합니다.
자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 *AWS CodeBuild API 참조*의 [WebHookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)를 참조하세요.
이 예제에서는 Webhook 필터 그룹이 pull 요청에 대해서만 빌드를 트리거합니다.
![\[pull 요청에 대해서만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-bitbucket.png)
두 필터 그룹을 사용하는 예제에서는 하나 또는 두 필터 그룹이 true로 평가되면 빌드가 트리거됩니다.
+ 첫 번째 필터 그룹은 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름과 `^refs/heads/branch1!`와 일치하는 헤드 참조를 갖는 브랜치에서 생성 또는 업데이트된 pull 요청을 지정합니다.
+ 두 번째 필터 그룹은 정규식 `^refs/heads/branch1$`와 일치하는 Git 참조 이름을 갖는 브랜치에서 push 요청을 지정합니다.
![\[두 필터 그룹의 예입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-head-base-regexes-bitbucket.png)
이 예제에서는 Webhook 필터 그룹이 태그 이벤트를 제외한 모든 요청에 대해 빌드를 트리거합니다.
![\[태그 이벤트를 제외한 모든 요청에 대해 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-exclude-bitbucket.png)
이 예제에서는 Webhook 필터 그룹이 정규식 `^buildspec.*`와 일치하는 이름을 갖는 파일이 변경될 때만 빌드를 트리거합니다.
![\[파일이 지정된 정규식과 일치하는 이름을 갖는 경우에만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-regex.png)
이 예제에서 Webhook 필터 그룹은 파일이 `src` 또는 `test` 폴더에서 변경된 경우에만 빌드를 트리거합니다.
![\[파일이 지정된 폴더에서 변경된 경우에만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-combined-regex.png)
이 예제에서는 Webhook 필터 그룹이 계정 ID가 정규식 `actor-account-id`와 일치하지 않는 Bitbucket 사용자가 변경을 수행한 경우에만 빌드를 트리거합니다.
**참고**
Bitbucket 계정 ID를 확인하는 자세한 방법은 https://api.bitbucket.org/2.0/users/*user-name*을 참조하십시오. 여기서 *user-name*은 사용자의 Bitbucket 사용자 이름입니다.
![\[계정 ID가 없는 Bitbucket 사용자가 변경을 수행한 경우에만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-actor-bitbucket.png)
이 예제에서 webhook 필터 그룹은 헤드 커밋 메시지가 정규식 `\[CodeBuild\]`와 일치할 때 푸시 이벤트에 대한 빌드를 트리거합니다.
![\[헤드 커밋 메시지가 정규식과 일치할 때 푸시 이벤트에 대한 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-commit-message.png)
# Bitbucket Webhook 이벤트 필터링(SDK)
AWS CodeBuild SDK를 사용하여 웹후크 이벤트를 필터링하려면 `CreateWebhook` 또는 `UpdateWebhook` API 메서드의 요청 구문에서 `filterGroups` 필드를 사용합니다. 자세한 내용은 *CodeBuild API 참조*의 [WebHookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)를 참조하세요.
pull 요청에 대해서만 빌드를 트리거하는 Webhook 필터를 생성하려면 요청 구문에 다음을 삽입합니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
}
]
]
```
지정된 브랜치에 대해서만 빌드를 트리거하는 Webhook 필터를 생성하려면 `pattern` 파라미터를 사용하여 브랜치 이름을 필터링하는 정규식을 지정합니다. 두 필터 그룹을 사용하는 예제에서는 하나 또는 두 필터 그룹이 true로 평가되면 빌드가 트리거됩니다.
+ 첫 번째 필터 그룹은 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름과 `^refs/heads/myBranch$`와 일치하는 헤드 참조를 갖는 브랜치에서 생성 또는 업데이트된 pull 요청을 지정합니다.
+ 두 번째 필터 그룹은 정규식 `^refs/heads/myBranch$`와 일치하는 Git 참조 이름을 갖는 브랜치에서 push 요청을 지정합니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_CLOSED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/heads/myBranch$"
},
{
"type": "BASE_REF",
"pattern": "^refs/heads/main$"
}
],
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "HEAD_REF",
"pattern": "^refs/heads/myBranch$"
}
]
]
```
`excludeMatchedPattern` 파라미터를 사용하여 빌드를 트리거하지 않을 이벤트를 지정할 수 있습니다. 이 예제에서는 태그 이벤트를 제외한 모든 요청에 대해 빌드가 트리거됩니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/tags/.*",
"excludeMatchedPattern": true
}
]
]
```
계정 ID가 `actor-account-id`인 Bitbucket 사용자가 변경을 수행한 경우에만 빌드를 트리거하는 필터를 생성할 수 있습니다.
**참고**
Bitbucket 계정 ID를 확인하는 자세한 방법은 https://api.bitbucket.org/2.0/users/*user-name*을 참조하십시오. 여기서 *user-name*은 사용자의 Bitbucket 사용자 이름입니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
},
{
"type": "ACTOR_ACCOUNT_ID",
"pattern": "actor-account-id"
}
]
]
```
`pattern` 인수의 정규식과 일치하는 이름을 갖는 파일이 변경되는 경우에만 빌드를 트리거하는 필터를 생성할 수 있습니다. 이 예제에서는 필터 그룹이 정규식 `^buildspec.*`와 일치하는 이름을 갖는 파일이 변경될 때만 빌드가 트리거되도록 지정합니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^buildspec.*"
}
]
]
```
이 예제에서 필터 그룹은 파일이 `src` 또는 `test` 폴더에서 변경될 때만 빌드가 트리거되도록 지정합니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^src/.+|^test/.+"
}
]
]
```
헤드 커밋 메시지가 패턴 인수의 정규식과 일치할 때만 빌드를 트리거하는 필터를 생성할 수 있습니다. 이 예제에서 필터 그룹은 푸시 이벤트의 헤드 커밋 메시지가 정규식 `\[CodeBuild\]`와 일치할 때만 빌드가 트리거되도록 지정합니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "COMMIT_MESSAGE",
"pattern": "\[CodeBuild\]"
}
]
]
```
# Bitbucket Webhook 이벤트 필터링(CloudFormation)
CloudFormation 템플릿을 사용하여 웹후크 이벤트를 필터링하려면 AWS CodeBuild 프로젝트의 `FilterGroups` 속성을 사용합니다. 다음 CloudFormation 템플릿의 YAML 형식 부분은 두 개의 필터 그룹을 생성합니다. 이들은 하나 또는 둘 모두 true로 평가되면 빌드를 트리거합니다.
+ 첫 번째 필터 그룹은 계정 ID가 `12345`와 일치하지 않는 Bitbucket 사용자가 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름을 갖는 브랜치에서 생성 또는 업데이트한 pull 요청을 지정합니다.
+ 두 번째 필터 그룹은 정규식 `^refs/heads/.*`와 일치하는 Git 참조 이름을 갖는 브랜치에서 생성되는 push 요청을 지정합니다.
+ 세 번째 필터 그룹은 정규식 `\[CodeBuild\]`와 일치하는 헤드 커밋 메시지에서 push 요청을 지정합니다.
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: BITBUCKET
Location: source-location
Triggers:
Webhook: true
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
- Type: BASE_REF
Pattern: ^refs/heads/main$
ExcludeMatchedPattern: false
- Type: ACTOR_ACCOUNT_ID
Pattern: 12345
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: HEAD_REF
Pattern: ^refs/heads/.*
- Type: FILE_PATH
Pattern: READ_ME
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: COMMIT_MESSAGE
Pattern: \[CodeBuild\]
- Type: FILE_PATH
Pattern: ^src/.+|^test/.+
```
# GitHub 글로벌 및 조직 웹후크
CodeBuild GitHub 글로벌 또는 조직 웹후크를 사용하여 GitHub 조직 또는 엔터프라이즈 내의 모든 리포지토리에서 웹후크 이벤트를 기반으로 빌드를 시작할 수 있습니다. 글로벌 및 조직 웹후크는 기존 GitHub 웹후크 이벤트 유형에서 작동하며 CodeBuild 웹후크를 생성할 때 범위 구성을 추가하여 구성할 수 있습니다. 글로벌 및 조직 웹후크를 사용하여 [ CodeBuild 내에서 자체 호스팅 GitHub Action 실행기를 설정](action-runner.md)하여 단일 프로젝트 내의 여러 리포지토리에서 `WORKFLOW_JOB_QUEUED` 이벤트를 수신할 수도 있습니다.
**Topics**
+ [글로벌 또는 조직 GitHub 웹후크 설정](github-global-organization-webhook-setup.md)
+ [GitHub 글로벌 또는 조직 웹후크 이벤트 필터링(콘솔)](github-global-organization-webhook-events-console.md)
+ [GitHub 조직 웹후크 이벤트 필터링(CloudFormation)](github-organization-webhook-events-cfn.md)
# 글로벌 또는 조직 GitHub 웹후크 설정
글로벌 또는 조직 GitHub 웹후크를 설정하는 상위 단계는 다음과 같습니다. 글로벌 및 조직 GitHub 웹후크에 대한 자세한 내용은 [GitHub 글로벌 및 조직 웹후크](github-global-organization-webhook.md) 섹션을 참조하세요.
1. 프로젝트의 소스 위치를 `CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION`으로 설정합니다.
1. 웹후크의 범위 구성에서 범위가 조직인지 [글로벌 웹후크](https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/exploring-user-activity-in-your-enterprise/managing-global-webhooks)인지에 따라 `GITHUB_ORGANIZATION` 또는 `GITHUB_GLOBAL` 중 하나로 설정합니다. 자세한 내용은 [웹후크 유형](https://docs.github.com/en/webhooks/types-of-webhooks)을 참조하세요.
1. 웹후크의 범위 구성의 일부로 이름을 지정합니다. 조직 웹후크의 경우 조직 이름이고 글로벌 웹후크의 경우 엔터프라이즈 이름입니다.
**참고**
프로젝트의 소스 유형이 `GITHUB_ENTERPRISE`인 경우 웹후크 범위 구성의 일부로 도메인을 지정해야 합니다.
1. (선택 사항) 조직 또는 엔터프라이즈 내의 특정 리포지토리에 대해서만 웹후크 이벤트를 수신하려면 웹후크를 생성할 때 `REPOSITORY_NAME`을 필터로 지정할 수 있습니다.
1. 조직 웹후크를 생성하는 경우 CodeBuild에 GitHub 내에서 조직 수준 웹후크를 생성할 수 있는 권한이 있는지 확인합니다. 조직 웹후크 권한을 사용하여 GitHub 개인 액세스 토큰을 생성하거나 CodeBuild OAuth를 사용할 수 있습니다. 자세한 내용은 [GitHub 및 GitHub Enterprise Server 액세스 토큰](access-tokens-github.md) 단원을 참조하십시오.
조직 웹후크는 기존 GitHub 웹후크 이벤트 유형에서 작동합니다.
1. 글로벌 웹후크를 생성하는 경우 웹후크를 수동으로 생성해야 합니다. GitHub 내에서 웹후크를 수동으로 생성하는 방법에 대한 자세한 내용은 [GitHub 수동 웹후크](github-manual-webhook.md) 섹션을 참조하세요.
글로벌 웹후크는 `WORKFLOW_JOB_QUEUED` 이벤트 유형만 지원합니다. 자세한 내용은 [자습서: CodeBuild 호스팅 GitHub Action 실행기 구성](action-runner.md) 단원을 참조하십시오.
# GitHub 글로벌 또는 조직 웹후크 이벤트 필터링(콘솔)
콘솔을 통해 GitHub 프로젝트를 생성할 때 다음 옵션을 선택하여 프로젝트 내에 GitHub 글로벌 또는 조직 웹후크를 생성합니다. 글로벌 및 조직 GitHub 웹후크에 대한 자세한 내용은 [GitHub 글로벌 및 조직 웹후크](github-global-organization-webhook.md) 섹션을 참조하세요.
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.
1. 빌드 프로젝트를 생성합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 실행(콘솔)](run-build-console.md) 섹션을 참조하세요.
+ **소스**에서 다음과 같이 합니다.
+ **소스 공급자**에서 **GitHub** 또는 **GitHub Enterprise**를 선택합니다.
+ **리포지토리**에서 **GitHub 범위 웹후크**를 선택합니다.
GitHub 리포지토리는 자동으로 `CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION`으로 설정되며, 이는 글로벌 및 조직 웹후크에 필요한 소스 위치입니다.
**참고**
조직 웹후크를 사용하는 경우 CodeBuild에 GitHub 내에서 조직 수준 웹후크를 생성할 수 있는 권한이 있는지 확인합니다. [기존 OAuth 연결](oauth-app-github.md)을 사용하는 경우 CodeBuild에 이 권한을 부여하려면 연결을 다시 생성해야 할 수 있습니다. 또는 [CodeBuild 수동 웹후크 기능](github-manual-webhook.md)을 사용하여 수동으로 웹후크를 생성할 수 있습니다. 기존 GitHub OAuth 토큰이 있고 조직 권한을 추가하려는 경우 [OAuth 토큰의 권한을 취소](https://docs.github.com/en/apps/oauth-apps/using-oauth-apps/reviewing-your-authorized-oauth-apps)하고 CodeBuild 콘솔을 통해 토큰을 다시 연결할 수 있습니다.
![\[GitHub 범위 웹후크의 구성입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/github-organization-webhook-source.png)
+ **기본 소스 웹후크 이벤트**에서:
+ **범위 유형 **에서 조직 웹후크를 생성하는 경우 **조직 수준**을 선택하고 글로벌 웹후크를 생성하는 경우 **엔터프라이즈 수준**을 선택합니다.
+ 웹후크가 글로벌 웹후크인지 아니면 조직 웹후크인지에 따라 **이름**에 엔터프라이즈 또는 조직 이름을 입력합니다.
프로젝트의 소스 유형이 `GITHUB_ENTERPRISE`인 경우 웹후크 조직 구성의 일부로 도메인을 지정해야 합니다. 예를 들어 조직의 URL이 **https://domain.com/orgs/org-name**인 경우 도메인은 **https://domain.com**입니다.
**참고**
웹후크가 생성된 후에는 이 이름을 변경할 수 없습니다. 이름을 변경하려면 웹후크를 삭제하고 다시 생성할 수 있습니다. 웹후크를 완전히 제거하려면 프로젝트 소스 위치를 GitHub 리포지토리로 업데이트할 수도 있습니다.
![\[글로벌 또는 조직 웹후크의 구성입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/github-organization-webhook-primary-events.png)
+ (선택 사항) **웹후크 이벤트 필터 그룹**에서 [새 빌드를 트리거할 이벤트](github-webhook.md)를 지정할 수 있습니다. 특정 리포지토리의 웹후크 이벤트에서만 빌드를 트리거하는 필터로 `REPOSITORY_NAME`을 지정할 수도 있습니다.
![\[특정 리포지토리의 웹후크 이벤트에서만 빌드를 트리거하는 필터입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/github-organization-webhook-filter-groups.png)
이벤트 유형을 `WORKFLOW_JOB_QUEUED`로 설정하여 자체 호스팅 GitHub Action 실행기를 설정할 수도 있습니다. 자세한 내용은 [자습서: CodeBuild 호스팅 GitHub Action 실행기 구성](action-runner.md) 단원을 참조하십시오.
1. 기본값으로 계속 진행한 다음 **빌드 프로젝트 생성**을 선택합니다.
# GitHub 조직 웹후크 이벤트 필터링(CloudFormation)
CloudFormation 템플릿을 사용하여 조직 웹후크 이벤트를 필터링하려면 프로젝트의 `ScopeConfiguration` 속성을 사용합니다 AWS CodeBuild . 글로벌 및 조직 GitHub 웹후크에 대한 자세한 내용은 [GitHub 글로벌 및 조직 웹후크](github-global-organization-webhook.md) 섹션을 참조하세요.
**참고**
글로벌 웹후크 및 GitHub Enterprise 웹후크는에서 지원되지 않습니다 CloudFormation.
CloudFormation 템플릿의 다음 YAML 형식 부분은 4개의 필터 그룹을 생성합니다. 이들은 하나 또는 모두 true로 평가되면 빌드를 트리거합니다.
+ 첫 번째 필터 그룹은 계정 ID가 `12345`와 일치하지 않는 GitHub 사용자가 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름을 갖는 브랜치에서 생성 또는 업데이트한 pull 요청을 지정합니다.
+ 두 번째 필터 그룹은 정규식 `^refs/heads/.*`와 일치하는 Git 참조 이름을 갖는 브랜치에서 정규식 `READ_ME`와 일치하는 이름을 갖는 파일에 생성되는 push 요청을 지정합니다.
+ 세 번째 필터 그룹은 정규식 `\[CodeBuild\]`와 일치하는 헤드 커밋 메시지에서 push 요청을 지정합니다.
+ 네 번째 필터 그룹은 정규식 `\[CI-CodeBuild\]`와 일치하는 워크플로 이름을 가진 GitHub Action 워크플로 작업 요청을 지정합니다.
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: GITHUB
Location: source-location
Triggers:
Webhook: true
ScopeConfiguration:
Name: organization-name
Scope: GITHUB_ORGANIZATION
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
- Type: BASE_REF
Pattern: ^refs/heads/main$
ExcludeMatchedPattern: false
- Type: ACTOR_ACCOUNT_ID
Pattern: 12345
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: HEAD_REF
Pattern: ^refs/heads/.*
- Type: FILE_PATH
Pattern: READ_ME
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: COMMIT_MESSAGE
Pattern: \[CodeBuild\]
- Type: FILE_PATH
Pattern: ^src/.+|^test/.+
- - Type: EVENT
Pattern: WORKFLOW_JOB_QUEUED
- Type: WORKFLOW_NAME
Pattern: \[CI-CodeBuild\]
```
# GitHub 수동 웹후크
CodeBuild가 GitHub 내에서 웹후크를 자동으로 생성하려고 시도하지 않도록 수동 GitHub 웹후크를 구성할 수 있습니다. CodeBuild는 호출의 일부로 페이로드 URL을 반환하여 웹후크를 생성하고 GitHub 내에서 웹후크를 수동으로 생성하는 데 사용할 수 있습니다. CodeBuild가 GitHub 계정에서 웹후크를 생성할 수 있는 허용 목록에 없는 경우에도 빌드 프로젝트의 웹후크를 수동으로 생성할 수 있습니다.
다음 절차에 따라 GitHub 수동 웹후크를 생성합니다.
**GitHub 수동 웹후크를 생성하려면**
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.
1. 빌드 프로젝트를 생성합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 실행(콘솔)](run-build-console.md) 섹션을 참조하세요.
+ **소스**에서 다음과 같이 합니다.
+ **소스 공급자**에서 **GitHub**를 선택합니다.
+ **리포지토리**에 대해 **내 GitHub 계정의 리포지토리**를 선택합니다.
+ **리포지토리 URL**에 **https://github.com/*user-name*/*repository-name***을 입력합니다.
+ **기본 소스 웹후크 이벤트**에서:
+ **웹후크 - 선택 사항**에서 **코드 변경이 이 리포지토리로 푸시될 때마다 다시 빌드**를 선택합니다.
+ **추가 구성** 및 **수동 생성 - 선택 사항**을 선택하고 **GitHub 콘솔에서 이 리포지토리에 대한 웹후크 수동 생성**을 선택합니다.
1. 기본값으로 계속 진행한 다음 **빌드 프로젝트 생성**을 선택합니다. 나중에 사용할 **페이로드 URL** 및 **보안 암호** 값을 기록해 둡니다.
![\[수동 웹후크에 대한 페이로드 URL 및 보안 암호 구성입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/github-manual-webhook-values.png)
1. `https://github.com/user-name/repository-name/settings/hooks`에서 GitHub 콘솔을 열고 **웹후크 추가**를 선택합니다.
+ **페이로드 URL**에 앞서 기록한 페이로드 URL 값을 입력합니다.
+ **콘텐츠 유형**에 대해 **application/json**을 선택합니다.
+ **보안 암호**에 앞서 기록한 보안 암호 값을 입력합니다.
+ CodeBuild로 웹후크 페이로드를 전송할 개별 이벤트를 구성합니다. **이 웹후크를 트리거할 이벤트는 무엇입니까?**에서 **개별 이벤트 선택**을 선택한 다음, **푸시**, **Pull 요청** 및 **릴리스** 이벤트 중에서 선택합니다. `WORKFLOW_JOB_QUEUED` 이벤트에 대한 빌드를 시작하려면 **워크플로 작업**을 선택합니다. GitHub Action 실행기에 대한 자세한 내용은 [자습서: CodeBuild 호스팅 GitHub Action 실행기 구성](action-runner.md) 섹션을 참조하세요. CodeBuild에서 지원하는 이벤트 유형에 대한 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 섹션을 참조하세요.
1. **웹후크 추가**를 선택합니다.
# GitHub Webhook 이벤트
Webhook 필터 그룹을 사용하여 어느 GitHub Webhook 이벤트가 빌드를 트리거할지 지정할 수 있습니다. 예를 들어 특정 분기가 변경된 경우에만 빌드가 트리거되도록 지정할 수 있습니다.
하나 이상의 웹후크 필터 그룹을 생성하여 어느 웹후크 이벤트가 빌드를 트리거할지 지정할 수 있습니다. 필터 그룹이 true로 평가(그룹 내 모든 필터가 true로 평가)되면 빌드가 트리거됩니다. 필터 그룹을 생성할 때 다음을 지정합니다.
**이벤트**
GitHub의 경우 `PUSH`, `PULL_REQUEST_CREATED`, `PULL_REQUEST_UPDATED`, `PULL_REQUEST_REOPENED`, `PULL_REQUEST_MERGED`, `PULL_REQUEST_CLOSED`, `RELEASED`, `PRERELEASED` 및 `WORKFLOW_JOB_QUEUED` 이벤트 가운데 하나 이상을 선택할 수 있습니다. webhook 이벤트 유형은 webhook 페이로드의 `X-GitHub-Event` 헤더에 있습니다. `X-GitHub-Event` 헤더에서 `pull_request` 또는 `push`를 볼 수 있습니다. 풀 요청 이벤트의 경우 유형은 webhook 이벤트 페이로드의 `action` 필드에 있습니다. 다음 표에서는 `X-GitHub-Event` 헤더 값과 webhook 풀 요청 페이로드 `action` 필드 값이 사용 가능한 이벤트 유형에 매핑되는 방법을 보여 줍니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/github-webhook.html)
GitHub 및 GitHub Enterprise Server에서만 `PULL_REQUEST_REOPENED` 이벤트 유형을 사용할 수 있습니다. GitHub에서만 `RELEASED` 및 `PRERELEASED` 이벤트 유형을 사용할 수 있습니다. `WORKFLOW_JOB_QUEUED`에 대한 자세한 내용은 [자습서: CodeBuild 호스팅 GitHub Action 실행기 구성](action-runner.md) 섹션을 참조하세요.
**하나 이상의 선택적 필터**
정규식을 사용하여 필터를 지정합니다. 이벤트가 빌드를 트리거하려면 연결된 그룹 내의 필터가 모두 true로 평가되어야 합니다.
`ACTOR_ACCOUNT_ID`(콘솔의 `ACTOR_ID`)
GitHub 또는 GitHub Enterprise Server 계정 ID가 정규식 패턴과 일치하면 Webhook 이벤트가 빌드를 트리거합니다. webhook 페이로드에 있는 `sender` 객체의 `id` 속성에서 이 값을 찾을 수 있습니다.
`HEAD_REF`
헤드 참조가 정규식 패턴(예: `refs/heads/branch-name` 또는 `refs/tags/tag-name`)과 일치하면 webhook 이벤트가 빌드를 트리거합니다. 푸시 이벤트의 경우 webhook 페이로드의 `ref` 속성에서 참조 이름을 찾을 수 있습니다. 풀 요청 이벤트의 경우 webhook 페이로드에 있는 `head` 객체의 `ref` 속성에서 브랜치 이름을 찾을 수 있습니다.
`BASE_REF`
기본 참조가 정규식 패턴(예: `refs/heads/branch-name`)과 일치하면 webhook 이벤트가 빌드를 트리거합니다. 풀 요청 이벤트에서만 `BASE_REF` 필터를 사용할 수 있습니다. webhook 페이로드에 있는 `base` 객체의 `ref` 속성에서 브랜치 이름을 찾을 수 있습니다.
`FILE_PATH`
변경된 파일의 경로가 정규식 패턴과 일치하면 webhook가 빌드를 트리거합니다. `FILE_PATH` 필터는 GitHub push 및 pull 요청 이벤트와 GitHub Enterprise Server push 이벤트에서 사용할 수 있습니다. GitHub Enterprise Server pull 요청 이벤트에서는 사용할 수 없습니다.
`COMMIT_MESSAGE`
헤드 커밋 메시지가 정규식 패턴과 일치하면 webhook가 빌드를 트리거합니다. `COMMIT_MESSAGE` 필터는 GitHub push 및 pull 요청 이벤트와 GitHub Enterprise Server push 이벤트에서 사용할 수 있습니다. GitHub Enterprise Server pull 요청 이벤트에서는 사용할 수 없습니다.
`TAG_NAME`
릴리스의 태그 이름이 정규식 패턴과 일치하면 웹후크가 빌드를 트리거합니다. `TAG_NAME` 필터는 GitHub 릴리스 및 사전 릴리스된 요청 이벤트와 함께 사용할 수 있습니다.
`RELEASE_NAME`
릴리스 이름이 정규식 패턴과 일치하면 웹후크가 빌드를 트리거합니다. `RELEASE_NAME` 필터는 GitHub 릴리스 및 사전 릴리스된 요청 이벤트와 함께 사용할 수 있습니다.
`REPOSITORY_NAME`
리포지토리 이름이 정규식 패턴과 일치하면 웹후크가 빌드를 트리거합니다. `REPOSITORY_NAME` 필터는 GitHub 글로벌 또는 조직 웹후크에서만 사용할 수 있습니다.
`ORGANIZATION_NAME`
조직 이름이 정규식 패턴과 일치하면 웹후크가 빌드를 트리거합니다. `ORGANIZATION_NAME` 필터는 GitHub 글로벌 웹후크에서만 사용할 수 있습니다.
`WORKFLOW_NAME`
워크플로 이름이 정규식 패턴과 일치하면 웹후크가 빌드를 트리거합니다. `WORKFLOW_NAME` 필터는 GitHub Action 워크플로 작업 대기열 요청 이벤트와 함께 사용할 수 있습니다.
**참고**
GitHub 리포지토리의 webhook 설정에서 webhook 페이로드를 찾을 수 있습니다.
**Topics**
+ [GitHub Webhook 이벤트 필터링(콘솔)](github-webhook-events-console.md)
+ [GitHub Webhook 이벤트 필터링(SDK)](github-webhook-events-sdk.md)
+ [GitHub Webhook 이벤트 필터링(CloudFormation)](github-webhook-events-cfn.md)
# GitHub Webhook 이벤트 필터링(콘솔)
다음 지침에 따라 AWS Management Console을 사용하여 GitHub 웹후크 이벤트를 필터링합니다. GitHub 웹후크 이벤트 유형에 대한 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 섹션을 참조하세요.
**기본 소스 webhook 이벤트**에서 다음을 선택합니다. 이 섹션은 소스 리포지토리로 **GitHub 계정의 리포지토리**를 선택한 경우에만 사용할 수 있습니다.
1. 프로젝트를 생성할 때 **코드 변경이 이 리포지토리로 푸시될 때마다 다시 빌드**를 선택합니다.
1. **이벤트 유형**에서 하나 이상의 이벤트를 선택합니다.
1. 이벤트가 빌드를 트리거할 때를 필터링하려면 **Start a build under these conditions(다음 조건에서 빌드를 시작)**에서 하나 이상의 선택적 필터를 추가합니다.
1. 이벤트가 트리거되지 않을 때를 필터링하려면 **Don't start a build under these conditions(다음 조건에서 빌드를 시작하지 않음)**에서 하나 이상의 선택적 필터를 추가합니다.
1. 필요한 경우 **필터 그룹 추가**를 선택하여 다른 필터 그룹을 추가합니다.
자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 *AWS CodeBuild API 참조*의 [WebHookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)를 참조하세요.
이 예제에서는 Webhook 필터 그룹이 pull 요청에 대해서만 빌드를 트리거합니다.
![\[pull 요청에 대해서만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter.png)
두 Webhook 필터 그룹을 사용하는 예제에서는 하나 또는 두 필터 그룹이 true로 평가되면 빌드가 트리거됩니다.
+ 첫 번째 필터 그룹은 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름과 `^refs/heads/branch1$`와 일치하는 헤드 참조를 갖는 브랜치에서 생성되거나 업데이트되거나 다시 열린 pull 요청을 지정합니다.
+ 두 번째 필터 그룹은 정규식 `^refs/heads/branch1$`와 일치하는 Git 참조 이름을 갖는 브랜치에서 push 요청을 지정합니다.
![\[두 필터 그룹의 예입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-head-base-regexes.png)
이 예제에서는 Webhook 필터 그룹이 태그 이벤트를 제외한 모든 요청에 대해 빌드를 트리거합니다.
![\[태그 이벤트를 제외한 모든 요청에 대해 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-exclude.png)
이 예제에서는 Webhook 필터 그룹이 정규식 `^buildspec.*`와 일치하는 이름을 갖는 파일이 변경될 때만 빌드를 트리거합니다.
![\[파일이 지정된 정규식과 일치하는 이름을 갖는 경우에만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-regex.png)
이 예제에서 Webhook 필터 그룹은 파일이 `src` 또는 `test` 폴더에서 변경된 경우에만 빌드를 트리거합니다.
![\[파일이 지정된 폴더에서 변경된 경우에만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-combined-regex.png)
이 예제에서는 Webhook 필터 그룹이 계정 ID가 정규식 `actor-account-id`와 일치하는 지정된 GitHub 또는 GitHub Enterprise Server 사용자가 변경을 수행한 경우에만 빌드를 트리거합니다.
**참고**
GitHub 계정 ID를 확인하는 자세한 방법은 https://api.github.com/users/*user-name*을 참조하십시오. 여기서 *user-name*은 사용자의 GitHub 사용자 이름입니다.
![\[정규식과 일치하는 계정 ID를 가진 지정된 GitHub 사용자가 변경을 수행한 경우에만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-actor.png)
이 예제에서 webhook 필터 그룹은 헤드 커밋 메시지가 정규식 `\[CodeBuild\]`와 일치할 때 푸시 이벤트에 대한 빌드를 트리거합니다.
![\[헤드 커밋 메시지가 정규식과 일치할 때 푸시 이벤트에 대한 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-commit-message.png)
이 예제에서는 웹후크 필터 그룹이 GitHub Action 워크플로 작업 이벤트에 대한 빌드만 트리거합니다.
**참고**
CodeBuild는 웹후크에 **WORKFLOW\$1JOB\$1QUEUED** 이벤트 필터가 포함된 필터 그룹이 있는 경우에만 GitHub Action 워크플로 작업을 처리합니다.
![\[웹후크 필터 그룹은 GitHub Actions 워크플로 작업 이벤트에 대해서만 빌드를 트리거합니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/github-actions-workflow-job-queued-no-highlight.png)
이 예제에서 웹후크 필터 그룹은 정규식 `CI-CodeBuild`와 일치하는 워크플로 이름에 대한 빌드를 트리거합니다.
![\[웹후크 필터 그룹은 정규식과 일치하는 워크플로 이름에 대한 빌드를 트리거합니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/github-actions-workflow-job-specific.png)
# GitHub Webhook 이벤트 필터링(SDK)
AWS CodeBuild SDK를 사용하여 웹후크 이벤트를 필터링하려면 `CreateWebhook` 또는 `UpdateWebhook` API 메서드의 요청 구문에서 `filterGroups` 필드를 사용합니다. 자세한 내용은 *CodeBuild API 참조*의 [WebHookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)를 참조하세요.
GitHub 웹후크 이벤트 유형에 대한 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 섹션을 참조하세요.
pull 요청에 대해서만 빌드를 트리거하는 Webhook 필터를 생성하려면 요청 구문에 다음을 삽입합니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_REOPENED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
}
]
]
```
지정된 브랜치에 대해서만 빌드를 트리거하는 Webhook 필터를 생성하려면 `pattern` 파라미터를 사용하여 브랜치 이름을 필터링하는 정규식을 지정합니다. 두 필터 그룹을 사용하는 예제에서는 하나 또는 두 필터 그룹이 true로 평가되면 빌드가 트리거됩니다.
+ 첫 번째 필터 그룹은 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름과 `^refs/heads/myBranch$`와 일치하는 헤드 참조를 갖는 브랜치에서 생성되거나 업데이트되거나 다시 열린 pull 요청을 지정합니다.
+ 두 번째 필터 그룹은 정규식 `^refs/heads/myBranch$`와 일치하는 Git 참조 이름을 갖는 브랜치에서 push 요청을 지정합니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_REOPENED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/heads/myBranch$"
},
{
"type": "BASE_REF",
"pattern": "^refs/heads/main$"
}
],
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "HEAD_REF",
"pattern": "^refs/heads/myBranch$"
}
]
]
```
`excludeMatchedPattern` 파라미터를 사용하여 빌드를 트리거하지 않을 이벤트를 지정할 수 있습니다. 예를 들어 이 예제에서는 태그 이벤트를 제외한 모든 요청에 대해 빌드가 트리거됩니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_REOPENED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/tags/.*",
"excludeMatchedPattern": true
}
]
]
```
`pattern` 인수의 정규식과 일치하는 이름을 갖는 파일이 변경되는 경우에만 빌드를 트리거하는 필터를 생성할 수 있습니다. 이 예제에서는 필터 그룹이 정규식 `^buildspec.*`와 일치하는 이름을 갖는 파일이 변경될 때만 빌드가 트리거되도록 지정합니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^buildspec.*"
}
]
]
```
이 예제에서 필터 그룹은 파일이 `src` 또는 `test` 폴더에서 변경될 때만 빌드가 트리거되도록 지정합니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^src/.+|^test/.+"
}
]
]
```
계정 ID가 `actor-account-id`인 지정된 GitHub 또는 GitHub Enterprise Server 사용자가 변경을 수행한 경우에만 빌드를 트리거하는 필터를 생성할 수 있습니다.
**참고**
GitHub 계정 ID를 확인하는 자세한 방법은 https://api.github.com/users/*user-name*을 참조하십시오. 여기서 *user-name*은 사용자의 GitHub 사용자 이름입니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_REOPENED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
},
{
"type": "ACTOR_ACCOUNT_ID",
"pattern": "actor-account-id"
}
]
]
```
헤드 커밋 메시지가 패턴 인수의 정규식과 일치할 때만 빌드를 트리거하는 필터를 생성할 수 있습니다. 이 예제에서 필터 그룹은 푸시 이벤트의 헤드 커밋 메시지가 정규식 `\[CodeBuild\]`와 일치할 때만 빌드가 트리거되도록 지정합니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "COMMIT_MESSAGE",
"pattern": "\[CodeBuild\]"
}
]
]
```
GitHub Action 워크플로에 대한 빌드를 트리거하는 웹후크 필터를 생성하려면 요청 구문에 다음을 삽입합니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "WORKFLOW_JOB_QUEUED"
}
]
]
```
# GitHub Webhook 이벤트 필터링(CloudFormation)
CloudFormation 템플릿을 사용하여 웹후크 이벤트를 필터링하려면 AWS CodeBuild 프로젝트의 `FilterGroups` 속성을 사용합니다.
GitHub 웹후크 이벤트 유형에 대한 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 섹션을 참조하세요.
다음 CloudFormation 템플릿의 YAML 형식 부분은 두 개의 필터 그룹을 생성합니다. 이들은 하나 또는 둘 모두 true로 평가되면 빌드를 트리거합니다.
+ 첫 번째 필터 그룹은 계정 ID가 `12345`와 일치하지 않는 GitHub 사용자가 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름을 갖는 브랜치에서 생성 또는 업데이트한 pull 요청을 지정합니다.
+ 두 번째 필터 그룹은 정규식 `^refs/heads/.*`와 일치하는 Git 참조 이름을 갖는 브랜치에서 정규식 `READ_ME`와 일치하는 이름을 갖는 파일에 생성되는 push 요청을 지정합니다.
+ 세 번째 필터 그룹은 정규식 `\[CodeBuild\]`와 일치하는 헤드 커밋 메시지에서 push 요청을 지정합니다.
+ 네 번째 필터 그룹은 정규식 `\[CI-CodeBuild\]`와 일치하는 워크플로 이름을 가진 GitHub Action 워크플로 작업 요청을 지정합니다.
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: GITHUB
Location: source-location
Triggers:
Webhook: true
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
- Type: BASE_REF
Pattern: ^refs/heads/main$
ExcludeMatchedPattern: false
- Type: ACTOR_ACCOUNT_ID
Pattern: 12345
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: HEAD_REF
Pattern: ^refs/heads/.*
- Type: FILE_PATH
Pattern: READ_ME
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: COMMIT_MESSAGE
Pattern: \[CodeBuild\]
- Type: FILE_PATH
Pattern: ^src/.+|^test/.+
- - Type: EVENT
Pattern: WORKFLOW_JOB_QUEUED
- Type: WORKFLOW_NAME
Pattern: \[CI-CodeBuild\]
```
# GitLab 그룹 웹후크
CodeBuild GitLab 그룹 웹후크를 사용하여 GitLab 그룹 내의 모든 리포지토리에서 웹후크 이벤트를 기반으로 빌드를 시작할 수 있습니다. 그룹 웹후크는 기존 GitLab 웹후크 이벤트 유형에서 작동하며 CodeBuild 웹후크를 생성할 때 범위 구성을 추가하여 구성할 수 있습니다. 그룹 웹후크를 사용하여 [CodeBuild 내에서 자체 호스팅 GitLab 실행기를 설정](gitlab-runner.md)하여 단일 프로젝트 내의 여러 리포지토리에서 `WORKFLOW_JOB_QUEUED` 이벤트를 수신할 수도 있습니다.
**Topics**
+ [그룹 GitLab 웹후크 설정](gitlab-group-webhook-setup.md)
+ [GitLab 그룹 웹후크 이벤트 필터링(콘솔)](gitlab-group-webhook-events-console.md)
+ [GitLab 그룹 웹후크 이벤트 필터링(CloudFormation)](gitlab-group-webhook-events-cfn.md)
# 그룹 GitLab 웹후크 설정
그룹 GitLab 웹후크를 설정하는 상위 단계는 다음과 같습니다. 그룹 GitLab 웹후크에 대한 자세한 내용은 [GitLab 그룹 웹후크](gitlab-group-webhook.md) 섹션을 참조하세요.
1. 프로젝트의 소스 위치를 `CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION`으로 설정합니다.
1. 웹후크의 범위 구성에서 범위를 `GITLAB_GROUP`으로 설정합니다.
1. 웹후크의 범위 구성의 일부로 이름을 지정합니다. 그룹 웹후크의 경우 그룹 이름입니다.
**참고**
프로젝트의 소스 유형이 `GITLAB_SELF_MANAGED`인 경우 웹후크 범위 구성의 일부로 도메인을 지정해야 합니다.
1. (선택 사항) 조직 또는 엔터프라이즈 내의 특정 리포지토리에 대해서만 웹후크 이벤트를 수신하려면 웹후크를 생성할 때 `REPOSITORY_NAME`을 필터로 지정할 수 있습니다.
1. 그룹 웹후크를 생성할 때 CodeBuild에 GitLab 내에서 그룹 수준 웹후크를 생성할 권한이 있는지 확인합니다. 이를 위해 CodeConnections를 통해 CodeBuild OAuth를 사용할 수 있습니다. 자세한 내용은 [CodeBuild의 GitLab 액세스](access-tokens-gitlab-overview.md) 단원을 참조하십시오.
그룹 웹후크는 기존 GitLab 웹후크 이벤트 유형에서 작동합니다.
# GitLab 그룹 웹후크 이벤트 필터링(콘솔)
콘솔을 통해 GitLab 프로젝트를 생성할 때 다음 옵션을 선택하여 프로젝트 내에 GitLab 그룹 웹후크를 생성합니다. 그룹 GitLab 웹후크에 대한 자세한 내용은 [GitLab 그룹 웹후크](gitlab-group-webhook.md) 섹션을 참조하세요.
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.
1. 빌드 프로젝트를 생성합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 실행(콘솔)](run-build-console.md) 섹션을 참조하세요.
+ **소스**에서 다음과 같이 합니다.
+ **소스 공급자**에서 **GitLab** 또는 **GitLab Self Managed**를 선택합니다.
+ **리포지토리**에서 **GitLab 범위 웹후크**를 선택합니다.
GitLab 리포지토리는 그룹 웹후크에 필요한 소스 위치인 `CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION`으로 자동 설정됩니다.
**참고**
그룹 웹후크를 사용하는 경우 CodeBuild에 GitLab 내에서 그룹 수준 웹후크를 생성할 수 있는 권한이 있는지 확인합니다. [기존 OAuth 연결](access-tokens-gitlab-overview.md#connections-gitlab)을 사용하는 경우 CodeBuild에 이 권한을 부여하려면 연결을 다시 생성해야 할 수 있습니다.
![\[GitLab 범위 웹후크의 구성입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/gitlab-group-source.png)
+ **기본 소스 웹후크 이벤트**에서:
+ **그룹 이름**에 그룹 이름을 입력합니다.
프로젝트의 소스 유형이 `GITLAB_SELF_MANAGED`인 경우 웹후크 그룹 구성의 일부로 도메인을 지정해야 합니다. 예를 들어 그룹의 URL이 **https://domain.com/group/group-name**인 경우 도메인은 **https://domain.com**입니다.
**참고**
웹후크가 생성된 후에는 이 이름을 변경할 수 없습니다. 이름을 변경하려면 웹후크를 삭제하고 다시 생성할 수 있습니다. 웹후크를 완전히 제거하려면 프로젝트 소스 위치를 GitLab 리포지토리로 업데이트할 수도 있습니다.
![\[그룹 웹후크의 구성입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/gitlab-group-webhook-primary-events.png)
+ (선택 사항) **웹후크 이벤트 필터 그룹**에서 [새 빌드를 트리거할 이벤트](gitlab-webhook.md)를 지정할 수 있습니다. 특정 리포지토리의 웹후크 이벤트에서만 빌드를 트리거하는 필터로 `REPOSITORY_NAME`을 지정할 수도 있습니다.
![\[특정 리포지토리의 웹후크 이벤트에서만 빌드를 트리거하는 필터입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/github-organization-webhook-filter-groups.png)
이벤트 유형을 `WORKFLOW_JOB_QUEUED`로 설정하여 자체 호스팅 GitLab 실행기를 설정할 수도 있습니다. 자세한 내용은 [의 자체 관리형 GitLab 실행기 AWS CodeBuild](gitlab-runner.md) 단원을 참조하십시오.
1. 기본값으로 계속 진행한 다음 **빌드 프로젝트 생성**을 선택합니다.
# GitLab 그룹 웹후크 이벤트 필터링(CloudFormation)
CloudFormation 템플릿을 사용하여 그룹 웹후크 이벤트를 필터링하려면 프로젝트의 `ScopeConfiguration` 속성을 사용합니다 AWS CodeBuild . 그룹 GitLab 웹후크에 대한 자세한 내용은 [GitLab 그룹 웹후크](gitlab-group-webhook.md) 섹션을 참조하세요.
CloudFormation 템플릿의 다음 YAML 형식 부분은 4개의 필터 그룹을 생성합니다. 이들은 하나 또는 모두 true로 평가되면 빌드를 트리거합니다.
+ 첫 번째 필터 그룹은 계정 ID가 `12345`와 일치하지 않는 GitLab 사용자가 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름을 갖는 분기에서 생성 또는 업데이트한 pull 요청을 지정합니다.
+ 두 번째 필터 그룹은 정규식 `^refs/heads/.*`와 일치하는 Git 참조 이름을 갖는 브랜치에서 정규식 `READ_ME`와 일치하는 이름을 갖는 파일에 생성되는 push 요청을 지정합니다.
+ 세 번째 필터 그룹은 정규식 `\[CodeBuild\]`와 일치하는 헤드 커밋 메시지에서 push 요청을 지정합니다.
+ 네 번째 필터 그룹은 정규식 `\[CI-CodeBuild\]`와 일치하는 CI/CD 파이프라인 이름이 있는 GitLab CI/CD 파이프라인 작업 요청을 지정합니다.
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: GITLAB
Location: source-location
Triggers:
Webhook: true
ScopeConfiguration:
Name: group-name
Scope: GITLAB_GROUP
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
- Type: BASE_REF
Pattern: ^refs/heads/main$
ExcludeMatchedPattern: false
- Type: ACTOR_ACCOUNT_ID
Pattern: 12345
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: HEAD_REF
Pattern: ^refs/heads/.*
- Type: FILE_PATH
Pattern: READ_ME
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: COMMIT_MESSAGE
Pattern: \[CodeBuild\]
- Type: FILE_PATH
Pattern: ^src/.+|^test/.+
- - Type: EVENT
Pattern: WORKFLOW_JOB_QUEUED
- Type: WORKFLOW_NAME
Pattern: \[CI-CodeBuild\]
```
# GitLab 수동 웹후크
CodeBuild가 GitLab 내에서 웹후크를 자동으로 생성하려고 시도하지 않도록 수동 GitLab 웹후크를 구성할 수 있습니다. CodeBuild는 직접 호출의 일부로 페이로드 URL을 반환하여 웹후크를 생성하고 GitLab 내에서 웹후크를 수동으로 생성하는 데 사용할 수 있습니다. CodeBuild가 GitLab 계정에서 웹후크를 생성할 수 있는 허용 목록에 없는 경우에도 빌드 프로젝트의 웹후크를 수동으로 생성할 수 있습니다.
다음 절차에 따라 GitLab 수동 웹후크를 생성합니다.
**GitLab 수동 웹후크를 생성하려면**
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home)에서 AWS CodeBuild 콘솔을 엽니다.
1. 빌드 프로젝트를 생성합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 실행(콘솔)](run-build-console.md) 섹션을 참조하세요.
+ **소스**에서 다음과 같이 합니다.
+ **소스 공급자**에서 **GitLab**을 선택합니다.
+ **리포지토리**에 대해 **내 GitLab 계정의 리포지토리**를 선택합니다.
+ **리포지토리 URL**에 **https://gitlab.com/*user-name*/*repository-name***을 입력합니다.
+ **기본 소스 웹후크 이벤트**에서:
+ **웹후크 - 선택 사항**에서 **코드 변경이 이 리포지토리로 푸시될 때마다 다시 빌드**를 선택합니다.
+ **추가 구성** 및 **수동 생성 - 선택 사항**을 선택하고 **GitLab 콘솔에서 이 리포지토리에 대한 웹후크 수동 생성**을 선택합니다.
1. 기본값으로 계속 진행한 다음 **빌드 프로젝트 생성**을 선택합니다. 나중에 사용할 **페이로드 URL** 및 **보안 암호** 값을 기록해 둡니다.
1. `https://gitlab.com/user-name/repository-name/-/hooks`에서 GitLab 콘솔을 열고 **새 웹후크 추가**를 선택합니다.
+ **URL**에 앞서 기록한 페이로드 URL 값을 입력합니다.
+ **보안 암호 토큰**에 앞서 기록한 보안 암호 값을 입력합니다.
+ CodeBuild로 웹후크 페이로드를 전송할 개별 이벤트를 구성합니다. **트리거**에서 **푸시 이벤트**, **병합 요청 이벤트**. **릴리스 이벤트**, **작업 이벤트** 중에서 선택합니다. CodeBuild에서 지원하는 이벤트 유형에 대한 자세한 내용은 [GitLab 웹후크 이벤트](gitlab-webhook.md) 섹션을 참조하세요.
1. **웹후크 추가**를 선택합니다.
# GitLab 웹후크 이벤트
웹후크 필터 그룹을 사용하여 어느 GitLab 웹후크 이벤트가 빌드를 트리거할지 지정할 수 있습니다. 예를 들어 특정 분기가 변경된 경우에만 빌드가 트리거되도록 지정할 수 있습니다.
하나 이상의 웹후크 필터 그룹을 생성하여 어느 웹후크 이벤트가 빌드를 트리거할지 지정할 수 있습니다. 필터 그룹이 true로 평가(그룹 내 모든 필터가 true로 평가)되면 빌드가 트리거됩니다. 필터 그룹을 생성할 때 다음을 지정합니다.
**이벤트**
GitLab의 경우 `PUSH`, `PULL_REQUEST_CREATED`, `PULL_REQUEST_UPDATED`, `PULL_REQUEST_MERGED`, `PULL_REQUEST_REOPENED`, `PULL_REQUEST_CLOSED`, `RELEASED` 및 `WORKFLOW_JOB_QUEUED` 이벤트 가운데 하나 이상을 선택할 수 있습니다.
webhook의 이벤트 유형은 `X-GitLab-Event` 필드의 헤더에 있습니다. 다음 표에서는 `X-GitLab-Event` 헤더 값이 이벤트 유형에 매핑되는 방법을 보여 줍니다. `Merge Request Hook` 웹후크 이벤트의 경우 페이로드의 `object_atttributes.action`에는 병합 요청 유형에 대한 추가 정보가 포함됩니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/gitlab-webhook.html)
`PULL_REQUEST_MERGED`의 경우 풀 요청이 스쿼시 전략에 병합되고 풀 요청 분기가 닫히면 원래의 풀 요청 커밋은 더 이상 존재하지 않게 됩니다. 이 경우 `CODEBUILD_WEBHOOK_MERGE_COMMIT` 환경 변수에는 스쿼시된 병합 커밋의 식별자가 포함됩니다.
**하나 이상의 선택적 필터**
정규식을 사용하여 필터를 지정합니다. 이벤트가 빌드를 트리거하려면 연결된 그룹 내의 필터가 모두 true로 평가되어야 합니다.
`ACTOR_ACCOUNT_ID`(콘솔의 `ACTOR_ID`)
GitLab 계정 ID가 정규식 패턴과 일치하면 웹후크 이벤트가 빌드를 트리거합니다. Webhook 필터 페이로드에 있는 `actor` 객체의 `account_id` 속성에 이 값이 표시됩니다.
`HEAD_REF`
헤드 참조가 정규식 패턴(예: `refs/heads/branch-name` 및 `refs/tags/tag-name`)과 일치하면 webhook 이벤트가 빌드를 트리거합니다. `HEAD_REF` 필터가 브랜치나 태그의 Git 참조 이름을 평가합니다. Webhook 페이로드의 `push` 객체에 있는 `new` 객체의 `name` 필드에 브랜치 또는 태그 이름이 표시됩니다. pull 요청 이벤트의 경우 webhook 페이로드의 `source` 객체에 있는 `branch` 객체의 `name` 필드에 브랜치 이름이 표시됩니다.
`BASE_REF`
베이스 참조가 정규식 패턴과 일치하면 webhook 이벤트가 빌드를 트리거합니다. `BASE_REF` 필터는 풀 요청 이벤트에서만 작동합니다(예: `refs/heads/branch-name`). `BASE_REF` 필터가 브랜치의 Git 참조 이름을 평가합니다. Webhook 페이로드의 `destination` 객체에 있는 `branch` 객체의 `name` 필드에 브랜치 이름이 표시됩니다.
`FILE_PATH`
변경된 파일의 경로가 정규식 패턴과 일치하면 webhook가 빌드를 트리거합니다.
`COMMIT_MESSAGE`
헤드 커밋 메시지가 정규식 패턴과 일치하면 webhook가 빌드를 트리거합니다.
`WORKFLOW_NAME`
워크플로 이름이 정규식 패턴과 일치하면 웹후크가 빌드를 트리거합니다.
**참고**
GitLab 리포지토리의 웹후크 설정에서 웹후크 페이로드를 찾을 수 있습니다.
**Topics**
+ [GitLab 웹후크 이벤트 필터링(콘솔)](gitlab-webhook-events-console.md)
+ [GitLab 웹후크 이벤트 필터링(SDK)](gitlab-webhook-events-sdk.md)
+ [GitLab 웹후크 이벤트 필터링(CloudFormation)](gitlab-webhook-events-cfn.md)
# GitLab 웹후크 이벤트 필터링(콘솔)
다음 지침에 따라를 사용하여 웹후크 이벤트를 필터링 AWS Management Console 합니다. GitLab 웹후크 이벤트에 대한 자세한 내용은 [GitLab 웹후크 이벤트](gitlab-webhook.md) 섹션을 참조하세요.
1. 프로젝트를 생성할 때 **코드 변경이 이 리포지토리로 푸시될 때마다 다시 빌드**를 선택합니다.
1. **이벤트 유형**에서 하나 이상의 이벤트를 선택합니다.
1. 이벤트가 빌드를 트리거할 때를 필터링하려면 **Start a build under these conditions(다음 조건에서 빌드를 시작)**에서 하나 이상의 선택적 필터를 추가합니다.
1. 이벤트가 트리거되지 않을 때를 필터링하려면 **Don't start a build under these conditions(다음 조건에서 빌드를 시작하지 않음)**에서 하나 이상의 선택적 필터를 추가합니다.
1. **Add filter group(필터 그룹 추가)**를 선택하여 다른 필터 그룹을 추가합니다.
자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 *AWS CodeBuild API 참조*의 [WebHookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)를 참조하세요.
이 예제에서는 Webhook 필터 그룹이 pull 요청에 대해서만 빌드를 트리거합니다.
![\[pull 요청에 대해서만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-gitlab.png)
두 필터 그룹을 사용하는 예제에서는 하나 또는 두 필터 그룹이 true로 평가되면 빌드가 트리거됩니다.
+ 첫 번째 필터 그룹은 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름과 `^refs/heads/branch1!`와 일치하는 헤드 참조를 갖는 브랜치에서 생성 또는 업데이트된 pull 요청을 지정합니다.
+ 두 번째 필터 그룹은 정규식 `^refs/heads/branch1$`와 일치하는 Git 참조 이름을 갖는 브랜치에서 push 요청을 지정합니다.
![\[두 필터 그룹의 예입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-head-base-regexes-gitlab.png)
이 예제에서는 Webhook 필터 그룹이 태그 이벤트를 제외한 모든 요청에 대해 빌드를 트리거합니다.
![\[태그 이벤트를 제외한 모든 요청에 대해 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-exclude-gitlab.png)
이 예제에서는 Webhook 필터 그룹이 정규식 `^buildspec.*`와 일치하는 이름을 갖는 파일이 변경될 때만 빌드를 트리거합니다.
![\[파일이 지정된 정규식과 일치하는 이름을 갖는 경우에만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-regex-gitlab.png)
이 예제에서 Webhook 필터 그룹은 파일이 `src` 또는 `test` 폴더에서 변경된 경우에만 빌드를 트리거합니다.
![\[파일이 지정된 폴더에서 변경된 경우에만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-combined-regex-gitlab.png)
이 예제에서는 웹후크 필터 그룹이 정규식 `actor-account-id`와 일치하는 계정 ID가 없는 GitLab 사용자가 변경을 수행한 경우에만 빌드를 트리거합니다.
**참고**
GitLab 계정 ID를 확인하는 자세한 방법은 https://api.github.com/users/*user-name*을 참조하십시오. 여기서 *user-name*은 사용자의 GitLab 사용자 이름입니다.
![\[계정 ID가 없는 GitLab 사용자가 변경한 경우에만 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-actor-gitlab.png)
이 예제에서 webhook 필터 그룹은 헤드 커밋 메시지가 정규식 `\[CodeBuild\]`와 일치할 때 푸시 이벤트에 대한 빌드를 트리거합니다.
![\[헤드 커밋 메시지가 정규식과 일치할 때 푸시 이벤트에 대한 빌드를 트리거하는 웹후크 필터 그룹입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-webhook-filter-commit-message-gitlab.png)
# GitLab 웹후크 이벤트 필터링(SDK)
AWS CodeBuild SDK를 사용하여 웹후크 이벤트를 필터링하려면 `CreateWebhook` 또는 `UpdateWebhook` API 메서드의 요청 구문에서 `filterGroups` 필드를 사용합니다. 자세한 내용은 *CodeBuild API 참조*의 [WebHookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)를 참조하세요.
GitLab 웹후크 이벤트에 대한 자세한 내용은 [GitLab 웹후크 이벤트](gitlab-webhook.md) 섹션을 참조하세요.
pull 요청에 대해서만 빌드를 트리거하는 Webhook 필터를 생성하려면 요청 구문에 다음을 삽입합니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED"
}
]
]
```
지정된 브랜치에 대해서만 빌드를 트리거하는 Webhook 필터를 생성하려면 `pattern` 파라미터를 사용하여 브랜치 이름을 필터링하는 정규식을 지정합니다. 두 필터 그룹을 사용하는 예제에서는 하나 또는 두 필터 그룹이 true로 평가되면 빌드가 트리거됩니다.
+ 첫 번째 필터 그룹은 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름과 `^refs/heads/myBranch$`와 일치하는 헤드 참조를 갖는 브랜치에서 생성 또는 업데이트된 pull 요청을 지정합니다.
+ 두 번째 필터 그룹은 정규식 `^refs/heads/myBranch$`와 일치하는 Git 참조 이름을 갖는 브랜치에서 push 요청을 지정합니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/heads/myBranch$"
},
{
"type": "BASE_REF",
"pattern": "^refs/heads/main$"
}
],
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "HEAD_REF",
"pattern": "^refs/heads/myBranch$"
}
]
]
```
`excludeMatchedPattern` 파라미터를 사용하여 빌드를 트리거하지 않을 이벤트를 지정할 수 있습니다. 이 예제에서는 태그 이벤트를 제외한 모든 요청에 대해 빌드가 트리거됩니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/tags/.*",
"excludeMatchedPattern": true
}
]
]
```
계정 ID가 `actor-account-id`인 GitLab 사용자가 변경을 수행한 경우에만 빌드를 트리거하는 필터를 생성할 수 있습니다.
**참고**
GitLab 계정 ID를 확인하는 자세한 방법은 https://api.github.com/users/*user-name*을 참조하십시오. 여기서 *user-name*은 사용자의 GitLab 사용자 이름입니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED"
},
{
"type": "ACTOR_ACCOUNT_ID",
"pattern": "actor-account-id"
}
]
]
```
`pattern` 인수의 정규식과 일치하는 이름을 갖는 파일이 변경되는 경우에만 빌드를 트리거하는 필터를 생성할 수 있습니다. 이 예제에서는 필터 그룹이 정규식 `^buildspec.*`와 일치하는 이름을 갖는 파일이 변경될 때만 빌드가 트리거되도록 지정합니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^buildspec.*"
}
]
]
```
이 예제에서 필터 그룹은 파일이 `src` 또는 `test` 폴더에서 변경될 때만 빌드가 트리거되도록 지정합니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^src/.+|^test/.+"
}
]
]
```
헤드 커밋 메시지가 패턴 인수의 정규식과 일치할 때만 빌드를 트리거하는 필터를 생성할 수 있습니다. 이 예제에서 필터 그룹은 푸시 이벤트의 헤드 커밋 메시지가 정규식 `\[CodeBuild\]`와 일치할 때만 빌드가 트리거되도록 지정합니다.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "COMMIT_MESSAGE",
"pattern": "\[CodeBuild\]"
}
]
]
```
# GitLab 웹후크 이벤트 필터링(CloudFormation)
CloudFormation 템플릿을 사용하여 웹후크 이벤트를 필터링하려면 AWS CodeBuild 프로젝트의 `FilterGroups` 속성을 사용합니다. GitLab 웹후크 이벤트에 대한 자세한 내용은 [GitLab 웹후크 이벤트](gitlab-webhook.md) 섹션을 참조하세요.
다음 CloudFormation 템플릿의 YAML 형식 부분은 두 개의 필터 그룹을 생성합니다. 이들은 하나 또는 둘 모두 true로 평가되면 빌드를 트리거합니다.
+ 첫 번째 필터 그룹은 계정 ID가 `12345`와 일치하지 않는 GitLab 사용자가 정규식 `^refs/heads/main$`와 일치하는 Git 참조 이름을 갖는 분기에서 생성 또는 업데이트한 pull 요청을 지정합니다.
+ 두 번째 필터 그룹은 정규식 `^refs/heads/.*`와 일치하는 Git 참조 이름을 갖는 브랜치에서 생성되는 push 요청을 지정합니다.
+ 세 번째 필터 그룹은 정규식 `\[CodeBuild\]`와 일치하는 헤드 커밋 메시지에서 push 요청을 지정합니다.
+ 네 번째 필터 그룹은 정규식 `\[CI-CodeBuild\]`와 일치하는 워크플로 이름을 가진 GitHub Action 워크플로 작업 요청을 지정합니다.
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: GITLAB
Location: source-location
Triggers:
Webhook: true
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
- Type: BASE_REF
Pattern: ^refs/heads/main$
ExcludeMatchedPattern: false
- Type: ACTOR_ACCOUNT_ID
Pattern: 12345
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: HEAD_REF
Pattern: ^refs/heads/.*
- - Type: EVENT
Pattern: PUSH
- Type: COMMIT_MESSAGE
Pattern: \[CodeBuild\]
- - Type: EVENT
Pattern: WORKFLOW_JOB_QUEUED
- Type: WORKFLOW_NAME
Pattern: \[CI-CodeBuild\]
```
# Buildkite 수동 웹후크
현재 CodeBuild에서는 모든 Buildkite 웹후크를 수동으로 생성해야 합니다. CodeBuild는 직접 호출의 일부로 페이로드 URL을 반환하여 웹후크를 생성합니다. 이 URL은 Buildkite 내에서 수동으로 웹후크를 생성하는 데 사용할 수 있습니다.
다음 절차에 따라 Buildkite 수동 웹후크를 생성합니다.
**웹후크를 사용하여 CodeBuild 프로젝트를 생성하려면**
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home)에서 AWS CodeBuild 콘솔을 엽니다.
1. 빌드 프로젝트를 생성합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 실행(콘솔)](run-build-console.md) 섹션을 참조하세요.
1. **프로젝트 구성**에서 **실행기 프로젝트**를 선택합니다.
**실행기**에서:
+ **실행기 공급자**에서 **Buildkite**를 선택합니다.
+ **Buildkite 에이전트 토큰**에서 **보안 암호 생성 페이지를 사용하여 새 에이전트 토큰 생성**을 선택합니다. AWS Secrets Manager에서 앞서 생성한 Buildkite 에이전트 토큰과 동일한 보안 암호 값을 가진 새 보안 암호를 생성하라는 메시지가 표시됩니다.
+ (선택 사항) 작업에 CodeBuild 관리형 자격 증명을 사용하려면 **Buildkite 소스 자격 증명 옵션**에서 작업의 소스 리포지토리 공급자를 선택하고 자격 증명이 계정에 대해 구성되어 있는지 확인합니다. 또한, Buildkite 파이프라인이 **HTTPS를 사용한 체크아웃**을 사용하는지 확인합니다.
1.
+ **환경**에서 다음과 같이 합니다.
+ 지원되는 **환경 이미지**와 **컴퓨팅**을 선택합니다. GitHub Action 워크플로 YAML의 레이블을 사용하여 이미지 및 인스턴스 설정을 재정의할 수 있는 옵션이 있습니다. 자세한 내용은 [2단계: GitHub Action 워크플로 YAML 업데이트](action-runner.md#sample-github-action-runners-update-yaml) 섹션을 참조하세요.
+ **Buildspec**에서 다음과 같이 합니다.
+ `buildspec-override:true`가 레이블로 추가되지 않는 한 buildspec은 무시됩니다. 대신 CodeBuild는 자체 호스팅 실행기를 설정하는 명령을 사용하도록 재정의합니다.
1. 기본값으로 계속 진행한 다음 **빌드 프로젝트 생성**을 선택합니다.
1. **웹후크 생성** 팝업에서 **페이로드 URL** 및 **보안 암호** 값을 저장합니다. 팝업의 지침에 따라 새 Buildkite 조직 웹후크를 생성합니다.
# 풀 요청 설명 승인
CodeBuild는 풀 요청에 의해 트리거되는 빌드에 대한 추가 제어를 제공하는 풀 요청 빌드 정책을 지원합니다. 변경 사항을 검토할 수 있을 때까지 알 수 없는 사용자의 풀 요청을 자동으로 빌드하지 않을 수 있습니다. 이 기능을 사용하면 팀원 중 한 명이 먼저 코드를 검토한 다음 파이프라인을 실행하도록 요구할 수 있습니다. 이는 일반적으로 알 수 없는 기여자가 제출한 코드를 빌드할 때 보안 조치로 사용됩니다.
풀 요청 빌드 정책을 사용하면 CodeBuild가 기여자의 권한 및 승인 상태에 따라 풀 요청에 대한 빌드를 트리거하는 시기를 제어할 수 있습니다. 이는 퍼블릭 리포지토리 또는 외부 공동 작업자의 기여를 수락하는 리포지토리에 특히 중요합니다.
이 기능을 활성화하면 다음 중 하나에 해당하는 경우에만 풀 요청에 대해 빌드가 트리거됩니다.
+ 풀 요청이 신뢰할 수 있는 기여자에 의해 생성됩니다.
+ 신뢰할 수 있는 기여자가 특정 설명을 게시하여 풀 요청을 승인합니다.
## 작동 방식
**신뢰할 수 있는 기여자**
신뢰할 수 있는 기여자는 소스 제어 시스템의 현재 역할이 풀 요청 기반 정책에서 승인자 역할로 설정된 사용자입니다. 신뢰할 수 있는 기여자가 풀 요청을 생성하면 CodeBuild는 빌드를 자동으로 트리거하여 현재 동작을 유지합니다.
**신뢰할 수 없는 기여자**
신뢰할 수 없는 기여자는 승인자 역할 목록에 역할이 설정되지 않은 사용자입니다. 신뢰할 수 없는 기여자가 풀 요청을 생성하는 경우:
1. CodeBuild는 '빌드를 시작하는 데 풀 요청 승인 필요'라는 메시지와 함께 빌드 상태를 '실패'로 표시합니다.
1. 신뢰할 수 있는 기여자는 변경 사항을 검토하고 `/codebuild_run()`과 함께 설명을 게시하여 빌드를 트리거해야 합니다. 예를 들어 `/codebuild_run(046e8b67481d53bdc86c3f6affdd5d1afae6d369)`입니다.
1. CodeBuild는 해설자의 권한을 검증하고 승인된 경우 빌드를 트리거합니다.
1. 빌드 결과는 풀 요청 페이지에 다시 보고됩니다.
**설명 승인 구문**
신뢰할 수 있는 기여자는 다음 설명 형식을 사용하여 빌드를 승인할 수 있습니다.
+ `/codebuild_run(046e8b67481d53bdc86c3f6affdd5d1afae6d369)` - 지정된 커밋 SHA에서 빌드를 트리거합니다.
## 구성
**기본 동작**
풀 요청 빌드 정책은 새로 생성된 모든 CodeBuild 프로젝트에 대해 기본적으로 활성화됩니다.
**API 파라미터**
풀 요청 빌드 정책은 다음 작업의 `PullRequestBuildPolicy` 파라미터를 사용하여 구성됩니다.
+ `CreateWebhook`
+ `UpdateWebhook`
**`PullRequestBuildPolicy` 구조**
```
{
"requiresCommentApproval": "string",
"approverRoles": ["string", ...]
}
```
**`requiresCommentApproval`**
풀 요청에 대한 빌드를 트리거하기 전에 설명 기반 승인이 필요한 시기를 지정합니다. 이 설정은 빌드가 자동으로 실행되는지, 아니면 설명을 통한 명시적 승인이 필요한지를 결정합니다.
유형: 문자열
유효한 값:
+ `DISABLED` - 설명 승인 없이 트리거를 자동으로 빌드합니다.
+ `FORK_PULL_REQUESTS` - 포크된 리포지토리의 풀 요청만 설명 승인이 필요합니다(기여자가 승인자 역할 중 하나가 아닌 경우).
+ `ALL_PULL_REQUESTS` - 모든 풀 요청은 빌드를 실행하기 전에 설명 승인이 필요합니다(기여자가 승인자 역할 중 하나가 아닌 경우). 이것이 기본값입니다.
**`approverRoles`**
설명 승인이 필요한 경우 풀 요청 빌드에 대한 승인 권한이 있는 리포지토리 역할 목록입니다. 이러한 역할을 가진 사용자만 유효한 설명 승인을 제공할 수 있습니다. 풀 요청 기여자가 이러한 역할 중 하나인 경우 풀 요청 빌드가 자동으로 트리거됩니다.
유형: 문자열 배열
GitHub 프로젝트의 유효한 값(값은 GitHub 역할에 매핑됨):
+ `GITHUB_ADMIN` - 리포지토리 관리자
+ `GITHUB_MAINTAIN` - 리포지토리 유지 관리자
+ `GITHUB_WRITE` - 쓰기 권한이 있는 사용자
+ `GITHUB_TRIAGE` - 분류 권한이 있는 사용자
+ `GITHUB_READ` - 읽기 권한이 있는 사용자
+ 기본값: `["GITHUB_ADMIN", "GITHUB_MAINTAINER", "GITHUB_WRITE"]`
GitLab 프로젝트의 유효한 값(값은 GitLab 역할에 매핑됨):
+ `GITLAB_OWNER` - 리포지토리 소유자
+ `GITLAB_MAINTAINER` - 리포지토리 유지 관리자
+ `GITLAB_DEVELOPER` - 개발자 권한이 있는 사용자
+ `GITLAB_REPORTER` - 보고자 권한이 있는 사용자
+ `GITLAB_PLANNER` - 기획자 권한이 있는 사용자
+ `GITLAB_GUEST ` - 게스트 권한이 있는 사용자
+ 기본값: `["GITLAB_OWNER", "GITLAB_MAINTAINER", "GITLAB_DEVELOPER"]`
Bitbucket 프로젝트의 유효한 값(값은 Bitbucket 역할에 매핑됨):
+ `BITBUCKET_ADMIN ` - 리포지토리 관리자
+ `BITBUCKET_WRITE` - 쓰기 권한이 있는 사용자
+ `BITBUCKET_READ ` - 읽기 권한이 있는 사용자
+ 기본값: `["BITBUCKET_ADMIN", "BITBUCKET_WRITE"]`
## 예제
**모든 풀 요청에 대한 설명 승인 활성화**
AWS CodeBuild SDK를 사용하여 웹후크에 대한 풀 요청 빌드 정책을 활성화하거나 비활성화하려면 `CreateWebhook` 또는 `UpdateWebhook` API 메서드의 요청 구문에서 `pullRequestBuildPolicy` 필드를 사용합니다. 자세한 내용은 *CodeBuild API 참조*의 [WebHookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)를 참조하세요.
GitHub에서 관리, 유지 관리 및 쓰기 역할을 가진 사용자는 신뢰할 수 있는 기여자로 처리됩니다.
```
"pullRequestBuildPolicy": {
"requiresCommentApproval": "ALL_PULL_REQUESTS",
"approverRoles": ["GITHUB_ADMIN", "GITHUB_MAINTAIN", "GITHUB_WRITE"]
}
```
**리포지토리 관리자 및 유지 관리자에 대해서만 설명 승인 활성화**
GitHub에서 관리, 유지 관리 역할을 가진 사용자는 신뢰할 수 있는 기여자로 처리됩니다.
```
"pullRequestBuildPolicy": {
"requiresCommentApproval": "FORK_PULL_REQUESTS",
"approverRoles": ["GITHUB_ADMIN", "GITHUB_MAINTAINER"]
}
```
**설명 승인 비활성화**
```
"pullRequestBuildPolicy": {
"requiresCommentApproval": "DISABLED"
}
```
## AWS CloudFormation
AWS CloudFormation 템플릿을 사용하여 웹후크에 대한 풀 요청 빌드 정책을 활성화하거나 비활성화하려면 PullRequestBuildPolicy 속성을 사용합니다. AWS CloudFormation 템플릿의 다음 YAML 형식 부분은 모든 풀 요청에 대해 풀 요청 빌드 정책이 활성화된 웹후크가 있는 프로젝트를 생성합니다. 유지 관리 및 관리 역할은 승인자로 지정됩니다.
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: BITBUCKET
Location: source-location
Triggers:
Webhook: true
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
- Type: BASE_REF
Pattern: ^refs/heads/main$
ExcludeMatchedPattern: false
PullRequestBuildPolicy:
RequiresCommentApproval: ALL_PULL_REQUESTS
ApproverRoles:
- GITHUB_MAINTAIN
- GITHUB_ADMIN
```
## 콘솔 구성
AWS 관리 콘솔을 사용하여 웹후크 이벤트를 필터링하려면:
1. **설명 승인**에서 모든 풀 요청(`ALL_PULL_REQUEST`)에 대해 비활성화 또는 활성화를 선택하거나 포크의 풀 요청(`FORK_PULL_REQUEST`)에 대해서만 비활성화 또는 활성화를 선택합니다.
1. **승인자 역할**에서 설명 승인이 필요할 때 풀 요청 빌드에 대한 승인 권한이 있는 리포지토리 역할을 선택합니다.
자세한 내용은 *CodeBuild API 참조*의 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)를 참조하세요.
![\[설명 승인이 있는 기본 소스 웹후크 이벤트 콘솔입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/pull-request-comment-approval.png)