- 그룹 웹후크
- GitLab에서 웹후크 구성하기
- 웹훅 요청 기록 보기
- 웹훅 수신 요구 사항
- 자동 비활성화된 웹후크
- 웹후크 테스트
- 전달 헤더
- 웹후크 디버그
- 웹후크 본문에 이미지 URL 표시 방법
- 상호 TLS를 지원하도록 웹후크 구성
- 웹후크 트래픽을 위한 방화벽 구성
- 관련 주제
- 문제 해결
웹후크
웹후크는 코드가 레포지토리에 푸시되거나 이슈에 댓글을 게시하는 이벤트에 의해 트리거되는 사용자 정의 HTTP 콜백입니다.
웹후크는 이벤트에 대한 JSON 데이터를 웹후크에 대해 구성된 URI로 전송합니다.
이벤트 및 웹후크 페이로드에 전송된 JSON 데이터에 대한 추가 정보는 웹후크 이벤트를 참조하세요.
웹후크를 사용하여 다음을 수행할 수 있습니다:
- CI/CD 작업을 트리거하고, 외부 이슈 트래커 및 백업 미러를 업데이트하거나, 프로덕션 서버에 배포합니다.
- Twilio와 통합하여 GitLab의 특정 프로젝트 또는 그룹에 이슈가 생성될 때마다 SMS 알림을 받습니다.
- 병합 요청에 자동으로 레이블을 할당합니다.
GitLab.com은 다음을 포함하는 웹후크 제한을 강제합니다:
- 프로젝트 또는 그룹당 최대 웹후크 수
- 분당 웹후크 호출 수
- 웹후크의 타임아웃 초
GitLab 셀프 관리의 경우, 관리자가 이러한 제한을 변경할 수 있습니다.
그룹 웹후크
그룹에서 그룹 및 하위 그룹의 모든 프로젝트에서 발생하는 이벤트에 의해 트리거되는 그룹 웹후크를 구성할 수 있습니다. 그룹과 프로젝트에서 동일한 웹후크를 구성하면, 두 웹후크 모두 프로젝트의 이벤트에 의해 트리거됩니다.
그룹 웹후크는 다음과 같은 그룹에 특정한 이벤트를 수신하도록 구성할 수도 있습니다:
GitLab에서 웹후크 구성하기
웹후크 생성하기
- GitLab 16.9에서 도입됨.
프로젝트 또는 그룹에 대한 웹후크를 생성하려면:
- 프로젝트 또는 그룹의 왼쪽 사이드바에서 설정 > 웹후크를 선택합니다.
- 새 웹후크 추가를 선택합니다.
-
URL에 웹후크 엔드포인트의 URL을 입력합니다.
URL에 하나 이상의 특수 문자가 포함된 경우 URL은 퍼센트 인코딩되어야 합니다. - 선택 사항. 이름에 웹후크의 이름을 입력합니다.
- 선택 사항. 설명에 웹후크의 설명을 입력합니다.
- 선택 사항. 비밀 토큰에 요청을 검증하기 위한 비밀 토큰을 입력합니다.
토큰은 웹후크 요청과 함께X-Gitlab-Token
HTTP 헤더에 전송됩니다.
웹후크 엔드포인트는 요청이 정당한지 확인하기 위해 이 토큰을 체크할 수 있습니다. - 트리거 섹션에서 웹후크를 트리거할 각 GitLab 이벤트에 대해 체크박스를 선택합니다.
- 선택 사항. SSL 검증 활성화 체크박스를 해제하여 SSL 검증을 비활성화합니다.
- 웹후크 추가를 선택합니다.
웹후크 URL의 민감한 부분 마스킹하기
웹후크가 실행될 때 민감한 부분을 정의하고 마스킹하여 구성된 값으로 교체할 수 있으며, 이는 여러 번 수행할 수 있습니다.
민감한 부분은 기록되지 않으며 데이터베이스에 안전하게 암호화됩니다.
웹후크 URL의 민감한 부분을 마스킹하려면:
- 프로젝트 또는 그룹의 왼쪽 사이드바에서 설정 > 웹후크를 선택합니다.
- URL에 전체 웹후크 URL을 입력합니다.
- URL의 부분 마스킹을 선택합니다.
- URL의 민감한 부분에 마스킹하려는 부분을 입력합니다.
- UI에서 어떻게 보이는지에 마스킹 값을 입력합니다.
각 웹후크에 대해 민감한 부분을 보간하려면 url_variables
를 사용하세요.
예를 들어, 웹후크에 다음 URL이 있을 경우:
https://webhook.example.com/{path}?key={value}
다음 변수를 정의해야 합니다:
path
value
변수 이름에는 소문자(a-z
), 숫자(0-9
), 또는 밑줄(_
)만 포함되어야 합니다.
REST API를 통해 URL 변수를 직접 정의할 수 있습니다.
사용자 정의 헤더
웹훅 구성에서 요청의 일환으로 최대 20개의 사용자 정의 헤더를 추가할 수 있습니다.
이 사용자 정의 헤더를 외부 서비스에 대한 인증에 사용할 수 있습니다.
사용자 정의 헤더는 전달 헤더의 값을 덮어쓰지 않아야 합니다.
헤더 이름은 다음과 같아야 합니다:
- 영문자, 숫자, 마침표, 하이픈 또는 밑줄만 포함해야 합니다.
- 영문자로 시작하고 영문자 또는 숫자로 끝나야 합니다.
- 연속된 마침표, 하이픈 또는 밑줄이 없어야 합니다.
사용자 정의 헤더는 값이 마스킹된 상태로 최근 이벤트에 표시됩니다.
사용자 정의 웹훅 템플릿
웹훅 구성에서 사용자 정의 페이로드 템플릿을 설정할 수 있습니다.
요청 본문은 현재 이벤트에 대한 데이터로 템플릿에서 렌더링됩니다.
템플릿은 유효한 JSON으로 렌더링되어야 합니다.
이벤트의 페이로드에서 모든 필드를 사용할 수 있으며, 예를 들어 , {{build_name}}
은 작업 이벤트의 경우 사용하고, {{deployable_url}}
은 배포 이벤트의 경우 사용합니다.
객체에 중첩된 속성에 접근하려면, 경로 세그먼트를 마침표로 구분하여 지정합니다.
다음과 같은 사용자 정의 페이로드 템플릿이 주어졌을 때:
{
"event": "{{object_kind}}",
"project_name": "{{project.name}}"
}
요청 페이로드는 push
이벤트와 템플릿을 결합합니다:
{
"event": "push",
"project_name": "Example"
}
사용자 정의 웹훅 템플릿은 배열의 속성에 접근할 수 없습니다.
이 기능에 대한 지원은 이슈 463332에서 제안되었습니다.
브랜치로 푸시 이벤트 필터링
브랜치로 푸시 이벤트를 필터링할 수 있습니다. 다음 옵션 중 하나를 사용하여 어떤 푸시 이벤트가 웹훅 엔드포인트로 전송되는지를 필터링할 수 있습니다:
- 모든 브랜치: 모든 브랜치의 푸시 이벤트.
-
와일드카드 패턴: 와일드카드 패턴과 일치하는 브랜치에서의 푸시 이벤트(예:
*-stable
또는production/*
). -
정규 표현식: 정규 표현식(regex)과 일치하는 브랜치에서의 푸시 이벤트.
정규 표현식 패턴은 RE2 구문을 따라야 합니다.
예를 들어,
main
을 제외하려면 다음을 사용할 수 있습니다:\b(?:m(?!ain\b)|ma(?!in\b)|mai(?!n\b)|[a-l]|[n-z])\w*|\b\w{1,3}\b|\W+
프로젝트 또는 그룹에 대한 브랜치 필터링을 구성하려면, GitLab에서 웹훅 구성하기를 참조하세요.
웹훅 요청 기록 보기
- GitLab 15.3에서 도입된 그룹 웹훅에 대한 최근 이벤트를 확인하세요. 도입된
사전 요구 사항:
- 프로젝트 웹훅의 경우, 해당 프로젝트에 대해 최소한 Maintainer 역할이 있어야 합니다.
- 그룹 웹훅의 경우, 해당 그룹에 대해 Owner 역할이 있어야 합니다.
GitLab은 각 웹훅 요청의 기록을 기록합니다.
최근 이벤트에서 지난 이틀 동안 웹훅에 대해 발생한 모든 요청을 확인할 수 있습니다.
웹훅의 요청 기록을 보려면:
- 왼쪽 사이드 바에서 검색 또는 이동을 선택하고 프로젝트나 그룹을 찾습니다.
- 설정 > 웹훅을 선택합니다.
- 웹훅에 대해 편집을 선택합니다.
- 최근 이벤트 섹션으로 이동합니다.
테이블에는 각 요청에 대한 다음 세부 정보가 포함됩니다:
- HTTP 상태 코드(
200
-299
코드는 초록색, 나머지는 빨간색, 실패한 전송은internal error
) - 트리거된 이벤트
- 요청의 경과 시간
- 요청이 전송된 상대 시간
요청 및 응답 세부 정보 검사
사전 요구 사항:
- 프로젝트 웹훅의 경우, 해당 프로젝트에 대해 최소한 Maintainer 역할이 있어야 합니다.
- 그룹 웹훅의 경우, 해당 그룹에 대해 Owner 역할이 있어야 합니다.
최근 이벤트의 각 웹훅 요청은 요청 세부 정보 페이지가 있습니다.
이 페이지는 다음의 본문 및 헤더를 포함합니다:
- 웹훅 수신 엔드포인트에서 GitLab이 받은 응답
- GitLab이 보낸 웹훅 요청
웹훅 이벤트의 요청 및 응답 세부 정보를 검사하려면:
- 왼쪽 사이드 바에서 검색 또는 이동을 선택하고 프로젝트나 그룹을 찾습니다.
- 설정 > 웹훅을 선택합니다.
- 웹훅에 대해 편집을 선택합니다.
- 최근 이벤트 섹션으로 이동합니다.
- 해당 이벤트에 대해 세부정보 보기를 선택합니다.
같은 데이터와 같은 Idempotency-Key
헤더로 요청을 다시 전송하려면 요청 다시 전송을 선택합니다.
웹훅 URL이 변경된 경우 요청을 다시 전송할 수 없습니다.
프로그래밍 방식으로 다시 전송하려면 API 문서를 참조하십시오.
웹훅 수신 요구 사항
웹훅 수신 엔드포인트는 빠르고 안정적이어야 합니다.
느리고 불안정한 수신자는 시스템 신뢰성을 보장하기 위해 자동으로 비활성화될 수 있습니다.
타임아웃된 웹훅은 중복 이벤트로 이어질 수 있습니다.
엔드포인트는 다음 모범 사례를 따라야 합니다:
-
200
또는201
상태 응답으로 신속하게 응답하세요.
요청 내에서 웹훅에 대한 중요한 처리를 피하세요.
대신 수신된 후 웹훅을 처리하기 위해 큐를 구현하세요.
타임아웃 제한 전에 응답하지 않는 웹훅 수신자는 GitLab.com에서 자동으로 비활성화될 수 있습니다. -
중복 이벤트를 처리할 준비를 하세요.
웹훅이 타임아웃된 경우 동일한 이벤트가 두 번 전송될 수 있습니다.
이 문제를 완화하기 위해, 엔드포인트가 신뢰할 수 있도록 빠르고 안정적이어야 합니다. -
응답 헤더 및 본문을 최소한으로 유지하세요.
GitLab은 문제 진단에 도움이 되도록 웹훅 요청 기록에서 나중에 검사할 수 있도록 응답 헤더와 본문을 저장합니다.
반환하는 헤더의 수와 크기를 제한해야 합니다.
웹훅 요청에 대해 빈 본문으로 응답할 수도 있습니다. -
웹훅이 잘못 구성되었음을 나타내기 위해 클라이언트 오류 상태 응답(
4xx
범위)만 반환하세요.
이 범위의 응답은 웹훅이 자동으로 비활성화될 수 있습니다.
예를 들어, 수신자가 푸시 이벤트만 지원하는 경우 문제 페이로드에 대해400
을 반환할 수 있습니다.
또는 인식되지 않은 이벤트 페이로드를 무시할 수 있습니다. -
이벤트가 처리된 경우
500
서버 오류 상태 응답을 절대 반환하지 마세요.
이러한 응답은 웹훅이 자동으로 비활성화될 수 있습니다. -
잘못된 HTTP 응답은 실패한 요청으로 간주됩니다.
자동 비활성화된 웹후크
자기 관리 GitLab에서는 기본적으로 이 기능이 사용할 수 없습니다. 이 기능을 사용할 수 있도록 하려면 관리자가 기능 플래그 auto_disabling_web_hooks
를 활성화해야 합니다.
GitLab.com에서는 이 기능이 사용 가능합니다. GitLab Dedicated에서는 이 기능이 사용할 수 없습니다.
연속적으로 네 번 실패하는 프로젝트 또는 그룹 웹후크는 자동으로 비활성화됩니다.
자동 비활성화된 웹후크를 보려면:
-
왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾습니다.
-
설정 > 웹후크를 선택합니다.
자동 비활성화된 웹후크는 다음과 같이 프로젝트 또는 그룹 웹후크 목록에 나타납니다:
-
웹후크가 일시적으로 비활성화된 경우 연결 실패
-
웹후크가 영구적으로 비활성화된 경우 연결 실패
일시적으로 비활성화된 웹후크
5xx
범위에서 응답 코드를 반환하거나 타임아웃 또는 다른 HTTP 오류를 경험하는 프로젝트 또는 그룹 웹후크는 간헐적으로 실패하는 것으로 간주되며 임시로 비활성화됩니다.
이 웹후크는 처음에 1분 동안 비활성화되며, 그 이후의 각각의 실패마다 최대 24시간까지 연장됩니다.
웹후크 수신자가 더 이상 오류를 반환하지 않는 경우 일시적으로 비활성화된 웹후크를 수동으로 다시 활성화할 수 있습니다.
영구적으로 비활성화된 웹후크
4xx
범위에서 응답 코드를 반환하는 프로젝트 또는 그룹 웹후크는 잘못 구성된 것으로 간주되며 영구적으로 비활성화됩니다.
이 웹후크는 수동으로 다시 활성화할 때까지 비활성화된 상태로 유지됩니다.
비활성화된 웹후크 다시 활성화
일시적 또는 영구적으로 비활성화된 웹후크를 수동으로 다시 활성화하려면 테스트 요청을 보내야 합니다.
테스트 요청이 2xx
범위의 응답 코드를 반환하면 웹후크가 다시 활성화됩니다.
웹후크 테스트
웹후크가 제대로 작동하는지 확인하기 위해 수동으로 웹후크를 트리거할 수 있습니다. 비활성화된 웹후크를 다시 활성화하기 위해 테스트 요청을 보낼 수도 있습니다.
예를 들어, push events
를 테스트하려면 프로젝트에 최소한 하나의 커밋이 있어야 합니다. 웹후크는 이 커밋을 사용합니다.
참고:
프로젝트 및 그룹 웹후크에 대해 일부 유형의 이벤트에 대한 테스트는 지원되지 않습니다. 자세한 내용은 이슈 379201을 참조하세요.
필수 조건:
-
프로젝트 웹후크를 테스트하려면 프로젝트에 대해 최소한 유지 관리 권한이 있어야 합니다.
-
그룹 웹후크를 테스트하려면 그룹에 대해 소유자 권한이 있어야 합니다.
웹후크를 테스트하려면:
-
프로젝트 또는 그룹에서 왼쪽 사이드바에 있는 설정 > 웹후크를 선택합니다.
-
구성된 웹후크 목록으로 스크롤합니다.
-
테스트 드롭다운 목록에서 테스트할 이벤트 유형을 선택합니다.
편집 페이지에서도 웹후크를 테스트할 수 있습니다.
전달 헤더
엔드포인트에 대한 웹후크 요청에는 다음 헤더가 포함됩니다:
헤더 | 설명 | 예시 |
---|---|---|
User-Agent |
"Gitlab/<VERSION>" 형식의 사용자 에이전트. |
"GitLab/15.5.0-pre" |
X-Gitlab-Instance |
웹후크를 보낸 GitLab 인스턴스의 호스트 이름. | "https://gitlab.com" |
X-Gitlab-Webhook-UUID |
웹후크당 고유한 ID. | "02affd2d-2cba-4033-917d-ec22d5dc4b38" |
X-Gitlab-Event |
웹후크 유형의 이름. 이벤트 유형에 해당하나 "<EVENT> Hook" 형식입니다. |
"Push Hook" |
X-Gitlab-Event-UUID |
재귀적이지 않은 웹후크당 고유한 ID. 후크는 GitLab 인스턴스에 도달한 이전 웹후크에 의해 트리거될 경우 재귀적입니다. 재귀 웹후크는 이 헤더에 대해 동일한 값을 가집니다. | "13792a34-cac6-4fda-95a8-c58e00a3954e" |
Idempotency-Key |
웹후크 재시도 간 일관성을 유지하는 고유 ID. 이 헤더를 사용하여 통합의 웹후크 효과의 항등성을 보장하세요. | "f5e5f430-f57b-4e6e-9fac-d9128cd7232f" |
웹후크 디버그
GitLab 웹후크를 디버그하고 페이로드를 캡처하려면 다음을 사용할 수 있습니다:
웹후크 이벤트 및 웹후크 페이로드에 전송된 JSON 데이터에 대한 정보는 웹후크 이벤트를 참조하세요.
공용 웹후크 검사 및 테스트 도구
공용 도구를 사용하여 웹후크 페이로드를 검사하고 테스트할 수 있습니다. 이 도구는 HTTP 요청을 위한 포괄적인 엔드포인트 역할을 하며 200 OK
HTTP 상태 코드로 응답합니다. 이러한 페이로드를 사용하여 웹후크 서비스를 개발할 수 있습니다.
이 도구를 사용할 때는 민감한 데이터를 외부 도구로 전송할 수 있으므로 주의해야 합니다.
이 도구와 함께 테스트 토큰을 사용하고 우발적으로 제3자에게 전송된 비밀을 회전해야 합니다.
웹후크 페이로드를 비공개로 유지하려면 개인 웹후크 수신기를 대신 생성하세요.
이러한 공용 도구에는 다음이 포함됩니다:
- Beeceptor: 임시 HTTPS 엔드포인트를 생성하고 수신 페이로드를 검사합니다.
- Webhook.site: 수신 페이로드를 검토합니다.
- Webhook Tester: 수신 페이로드를 검사하고 디버그합니다.
GitLab 개발 키트 (GDK)
보다 안전한 개발 환경을 위해, GitLab 개발 키트 (GDK)를 사용하여 GitLab 웹후크에 대해 로컬에서 개발할 수 있습니다. GDK를 사용하면 로컬 GitLab 인스턴스에서 로컬로 실행 중인 웹후크 수신기로 웹후크를 보낼 수 있습니다. 이 방법을 사용하려면 GDK를 설치하고 구성해야 합니다.
개인 웹후크 수신기 만들기
사전 요구 사항:
- Ruby가 설치되어 있어야 합니다.
공식 수신기로 웹후크 페이로드를 보낼 수 없는 경우, 자신만의 개인 웹후크 수신기를 만들 수 있습니다.
개인 웹후크 수신기를 만들려면:
-
다음 파일을
print_http_body.rb
로 저장합니다:require 'webrick' server = WEBrick::HTTPServer.new(:Port => ARGV.first) server.mount_proc '/' do |req, res| puts req.body end trap 'INT' do server.shutdown end server.start
-
사용되지 않는 포트(예:
8000
)를 선택하고 스크립트를 시작합니다:ruby print_http_body.rb 8000
-
GitLab에서 웹후크 구성을 하고 수신기 URL(예:
http://receiver.example.com:8000/
)을 추가합니다. -
테스트를 선택합니다. 콘솔에서 비슷한 메시지를 볼 수 있어야 합니다:
{"before":"077a85dd266e6f3573ef7e9ef8ce3343ad659c4e","after":"95cd4a99e93bc4bbabacfa2cd10e6725b1403c60",<SNIP>} example.com - - [14/May/2014:07:45:26 EDT] "POST / HTTP/1.1" 200 0 - -> /
이 수신기를 추가하려면, 로컬 네트워크에 대한 요청 허용이 필요할 수 있습니다.
웹후크 본문에 이미지 URL 표시 방법
상대 이미지 참조는 웹후크 본문에서 절대 URL을 사용하도록 다시 작성됩니다.
예를 들어, 이미지, 병합 요청, 댓글 또는 위키 페이지에 다음 이미지 참조가 포함되어 있는 경우:

- GitLab이
gitlab.example.com
에 설치되어 있습니다. - 프로젝트가
example-group/example-project
에 있습니다.
참조는 웹후크 본문에서 다음과 같이 다시 작성됩니다:

이미지 URL은 다음 경우에 다시 작성되지 않습니다:
- 이미 HTTP, HTTPS 또는 프로토콜 상대 URL을 가리키는 경우.
- 링크 레이블과 같이 고급 Markdown 기능을 사용하는 경우.
상호 TLS를 지원하도록 웹후크 구성
Offering: Self-managed
- 도입됨 GitLab 16.9에서.
사전 요구 사항:
- GitLab 관리자여야 합니다.
상호 TLS를 지원하도록 웹후크를 구성하려면 PEM 형식의 클라이언트 인증서를 구성해야 합니다. 이 인증서는 전역적으로 설정되며 TLS 핸드셰이크 중 서버에 제공됩니다. 인증서는 PEM 비밀번호로 보호할 수도 있습니다.
인증서를 구성하려면:
-
/etc/gitlab/gitlab.rb
를 편집합니다:gitlab_rails['http_client']['tls_client_cert_file'] = '<CLIENT PEM 파일 경로>' gitlab_rails['http_client']['tls_client_cert_password'] = '<선택적 비밀번호>'
-
파일을 저장하고 GitLab을 재구성합니다:
sudo gitlab-ctl reconfigure
-
docker-compose.yml
을 편집합니다:version: "3.6" services: gitlab: image: 'gitlab/gitlab-ee:latest' restart: always hostname: 'gitlab.example.com' environment: GITLAB_OMNIBUS_CONFIG: | gitlab_rails['http_client']['tls_client_cert_file'] = '<CLIENT PEM 파일 경로>' gitlab_rails['http_client']['tls_client_cert_password'] = '<선택적 비밀번호>'
-
파일을 저장하고 GitLab을 재시작합니다:
docker compose up -d
-
/home/git/gitlab/config/gitlab.yml
을 편집합니다:production: &base http_client: tls_client_cert_file: '<CLIENT PEM 파일 경로>' tls_client_cert_password: '<선택적 비밀번호>'
-
파일을 저장하고 GitLab을 재시작합니다:
# systemd를 사용하는 시스템용 sudo systemctl restart gitlab.target # SysV init를 사용하는 시스템용 sudo service gitlab restart
웹후크 트래픽을 위한 방화벽 구성
웹후크 트래픽을 위한 방화벽을 구성할 때, 웹후크는 일반적으로 Sidekiq 노드에서 비동기적으로 전송된다고 가정할 수 있습니다. 그러나 웹후크가 Rails 노드에서 동기적으로 전송되는 경우가 있습니다. 이러한 경우에는 다음과 같은 경우가 포함됩니다:
관련 주제
문제 해결
로컬 발급자 인증서를 가져올 수 없음
SSL 검증이 활성화된 경우, GitLab이 웹후크 엔드포인트의 SSL 인증서를 검증할 수 없다는 오류가 발생할 수 있습니다.
일반적으로 이 오류는 루트 인증서가 CAcert.org에 의해 신뢰할 수 있는 인증 기관에서 발급되지 않았기 때문에 발생합니다.
이 문제를 해결하려면, SSL Checker를 사용하여 오류를 식별하는 것을 고려하세요.
누락된 중간 인증서는 검증 실패의 일반적인 원인입니다.
웹후크가 트리거되지 않음
- GitLab 16.3에서 도입된 조용한 모드에서 웹후크가 트리거되지 않음 링크.
웹후크가 트리거되지 않는 경우 다음을 확인하세요:
-
웹후크가 자동으로 비활성화되지 않았는지 확인하세요.
-
GitLab 인스턴스가 조용한 모드가 아닙니다.