웹훅

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

웹훅은 이벤트에 트리거되는 사용자 정의 HTTP 콜백입니다. 예를 들어 리포지토리에 코드를 푸시하거나 이슈에 댓글을 게시하는 것과 같은 이벤트가 웹훅을 트리거합니다. 웹훅은 해당 이벤트에 대한 JSON 데이터를 웹훅에 구성된 URI로 보냅니다. 웹훅 페이로드에 전송된 이벤트에 대한 자세한 정보 및 JSON 데이터에 대해서는 웹훅 이벤트를 참조하세요.

웹훅을 사용하여 다음을 수행할 수 있습니다.

GitLab.com은 웹훅 제한을 적용합니다. 이에는 다음 사항이 포함됩니다.

  • 프로젝트 또는 그룹 당 웹훅의 최대 수
  • 분당 웹훅 호출 수
  • 웹훅 타임아웃 시간(초)

GitLab 자체 관리는 관리자가 이러한 제한을 변경할 수 있습니다.

그룹 웹훅

Tier: Premium, Ultimate

그룹 웹훅은 그룹 및 하위 그룹의 모든 프로젝트에서 발생하는 이벤트에 의해 트리거될 수 있는 웹훅입니다. 그룹 및 프로젝트에 동일한 웹훅을 구성하는 경우 둘 다 프로젝트의 이벤트에 의해 트리거됩니다.

그룹 웹훅은 또한 그룹에 특정한 이벤트를 청취하도록 구성할 수 있습니다. 이는 다음을 포함합니다.

GitLab에서 웹훅 구성

웹훅 생성

프로젝트 또는 그룹에 대한 웹훅을 생성하려면:

  1. 프로젝트 또는 그룹에서 왼쪽 사이드바에서 설정 > 웹훅을 선택합니다.
  2. 새 웹훅 추가를 선택합니다.
  3. URL에 웹훅 엔드포인트의 URL을 입력합니다. URL에 하나 이상의 특수 문자가 포함된 경우 URL은 퍼센트 인코딩되어야 합니다.
  4. 선택 사항. 이름에 웹훅의 이름을 입력합니다.
  5. 선택 사항. 설명에 웹훅의 설명을 입력합니다.
  6. 선택 사항. Secret token에 요청을 유효성 검사하는 비밀 토큰을 입력합니다.

    토큰은 웹훅 요청과 함께 X-Gitlab-Token HTTP 헤더에 전송됩니다. 웹훅 엔드포인트에서 토큰을 확인하여 요청이 유효한지 확인할 수 있습니다.

  7. 트리거 섹션에서 각 GitLab 이벤트에 대한 확인란을 선택합니다.
  8. 선택 사항. SSL 검증 비활성화 확인란 선택을 해제하려면.
  9. 웹훅 추가를 선택합니다.

웹훅 URL의 민감한 부분 마스킹

  • GitLab 15.5에서 플래그 webhook_form_mask_url로 소개됨. 기본적으로 비활성화됨.
  • GitLab 15.7에서 일반적으로 사용 가능. 기능 플래그 webhook_form_mask_url이 제거되었습니다.

웹훅 URL의 민감한 부분을 정의하고 마스킹된 값을 구성값으로 대체하여 웹훅이 실행될 때마다 수행할 수 있습니다. 민감한 부분은 기록되지 않으며 데이터베이스에 암호화되어 저장됩니다.

웹훅 URL의 민감한 부분을 마스킹하려면:

  1. 프로젝트 또는 그룹에서 왼쪽 사이드바에서 설정 > 웹훅을 선택합니다.
  2. URL에 전체 웹훅 URL을 입력합니다.
  3. URL 일부 마스킹을 선택합니다.
  4. URL의 민감한 부분에 마스킹하려는 부분을 입력합니다.
  5. UI에서 표시되는 방식에 마스킹 값을 입력합니다.

각 웹훅에 대해 민감한 부분의 값을 보간하려면 url_variables를 사용하세요. 예를 들어 웹훅에 다음과 같은 URL이 있는 경우:

https://webhook.example.com/{path}?key={value}

다음의 변수를 정의해야 합니다.

  • path
  • value

변수 이름은 소문자 (a-z), 숫자 (0-9), 또는 밑줄 (_)만 포함해야 합니다. URL 변수는 REST API를 사용하여 직접 정의할 수 있습니다.

사용자 정의 헤더

  • GitLab 16.11에서 플래그 custom_webhook_headers로 소개됨. 기본적으로 활성화됨.
  • GitLab 17.0에서 일반적으로 사용 가능. 기능 플래그 custom_webhook_headers가 제거되었습니다.

요청의 일부로 웹훅 구성에 최대 20개의 사용자 정의 헤더를 추가할 수 있습니다. 이 사용자 정의 헤더를 외부 서비스에 대한 인증에 사용할 수 있습니다.

사용자 정의 헤더는 배달 헤더의 값이 덮어써지지 않아야 합니다. 헤더 이름은 반드시 다음 조건을 충족해야 합니다.

  • 알파벳 문자, 점, 대시 또는 밑줄만 포함해야 합니다.
  • 문자로 시작하여 문자 또는 숫자로 끝나야 합니다.
  • 연속으로 점, 대시 또는 밑줄을 가질 수 없어야 합니다.

사용자 정의 헤더는 마스크된 값으로 최근 이벤트에 나타납니다.

사용자 정의 웹훅 템플릿

  • GitLab 16.10에서 플래그 custom_webhook_template로 소개됨. 기본적으로 활성화됨.
  • GitLab 17.0에서 일반적으로 사용 가능. 기능 플래그 custom_webhook_template가 제거되었습니다.

웹훅 구성에서 사용자 정의 페이로드 템플릿을 설정할 수 있습니다. 요청 본문은 현재 이벤트의 데이터로 템플릿에서 렌더링됩니다. 템플릿은 유효한 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은 각 웹훅 요청의 이력을 기록합니다. 최근 이벤트에서는 지난 2일간 웹훅에 의해 수행된 모든 요청을 볼 수 있습니다.

웹훅의 요청 기록을 보려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾으세요.
  2. 설정 > 웹훅을 선택합니다.
  3. 웹훅에 대해 편집을 선택합니다.
  4. 최근 이벤트 섹션으로 이동합니다.

표에는 각 요청에 대한 다음과 같은 세부 정보가 포함되어 있습니다:

  • HTTP 상태 코드 (200-299 코드에 대해 초록색, 그 외에는 빨간색, 실패한 전송에 대해 내부 오류)
  • 트리거된 이벤트
  • 요청의 경과 시간
  • 요청이 수행된 상대적 시간

최근 전달 사항

요청 및 응답 세부 정보 검사

필수 사항:

  • 프로젝트 웹훅의 경우, 프로젝트에 대한 유지자 역할이 있어야 합니다.
  • 그룹 웹훅의 경우, 그룹에 대한 소유자 역할이 있어야 합니다.

최근 이벤트에서 각 웹훅 요청에는 요청 세부 정보 페이지가 있습니다. 이 페이지에는 다음의 바디와 헤더가 포함되어 있습니다:

  • 웹훅 수신 엔드포인트에서 받은 GitLab의 응답
  • GitLab이 보낸 웹훅 요청

웹훅 이벤트의 요청 및 응답 세부 정보를 검사하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾으세요.
  2. 설정 > 웹훅을 선택합니다.
  3. 웹훅에 대해 편집을 선택합니다.
  4. 최근 이벤트 섹션으로 이동합니다.
  5. 이벤트에 대해 세부 정보 보기를 선택합니다.

동일한 데이터 및 동일한 Idempotency-Key 헤더)로 요청을 다시 보내려면 요청 다시 보내기를 선택하세요. 웹훅 URL이 변경된 경우 요청을 다시 보낼 수 없습니다. 프로그래밍 방식으로 재전송하려면 API 문서를 참조하세요.

웹훅 수신기 요구 사항

웹훅 수신기 엔드포인트는 빠르고 안정적이어야 합니다. 느린 및 불안정한 수신기는 시스템 신뢰성을 보장하기 위해 자동으로 비활성화될 수 있습니다. 타임아웃되는 웹훅은 중복 이벤트로 이어질 수 있습니다.

엔드포인트는 다음을 따라야 합니다:

  • 빠르게 200 또는 201 상태 응답을 제공하세요. 동일한 요청에서 웹훅을 처리하는 것을 피하십시오. 요청을 받은 후 웹훅을 처리하기 위해 큐를 구현하세요. 타임아웃 제한에 대해 응답하지 않는 웹훅 수신기는 GitLab.com에서 자동으로 비활성화될 수 있습니다.
  • 중복 이벤트를 처리할 수 있도록 준비하세요. 웹훅이 타임아웃되었다면, 동일한 이벤트가 두 번 전송될 수 있습니다. 이 문제를 완화하려면 엔드포인트가 신뢰할 만하도록 빠르고 안정적이도록 확인하세요.
  • 응답 헤더 및 바디를 최소한으로 유지하세요. GitLab은 응답 헤더와 바디를 저장하여 웹훅 요청 기록에서 이후 진단에 도움이 되도록 표시합니다. 반환된 헤더의 수와 크기를 제한해야 합니다. 또한 빈 바디로 웹훅 요청에 응답할 수 있습니다.
  • 웹훅이 잘못 구성된 경우에 대해서만 클라이언트 오류 상태 응답(4xx 범위)을 반환하세요. 이 범위의 응답은 웹훅을 자동으로 비활성화할 수 있습니다. 예를 들어, 수신기가 푸시 이벤트만 지원하는 경우에는 이슈 페이로드에 대해 400을 반환할 수 있습니다. 또는 인식되지 않는 이벤트 페이로드를 무시할 수 있습니다.
  • 이벤트가 처리된 경우 500 서버 오류 응답을 반환하지 마세요. 이러한 응답은 웹훅을 자동으로 비활성화할 수 있습니다.
  • 잘못된 HTTP 응답은 실패한 요청으로 처리됩니다.

자동으로 비활성화되는 웹훅

  • 프로젝트 웹훅의 경우, GitLab 15.7에서 일반적으로 사용 가능. Feature flag web_hooks_disable_failed가 제거되었습니다.
  • 그룹 웹훅의 경우, GitLab 15.10에서 도입되었습니다.
  • GitLab 15.10에서 자체 게시판에서는 기능 플래그 auto_disabling_web_hooks라는 플래그가 지정된 상태로 비활성화되었습니다.

플래그: 자체 게시판 GitLab의 경우, 기본적으로 이 기능은 사용할 수 없습니다. 이를 사용하려면 관리자가 auto_disabling_web_hooks라는 기능 플래그를 활성화해야 합니다. GitLab.com의 경우, 이 기능을 사용할 수 있습니다. GitLab Dedicated의 경우, 이 기능은 사용할 수 없습니다.

연속적으로 네 번의 실패한 프로젝트 또는 그룹 웹훅은 자동으로 비활성화됩니다.

자동으로 비활성화된 웹훅을 보려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾으세요.
  2. 설정 > 웹훅을 선택합니다.

자동으로 비활성화된 웹훅은 프로젝트 또는 그룹 웹훅 목록에 다음과 같이 나타납니다:

실패 웹훅의 배지

일시적으로 비활성화된 웹훅

5xx 범위에서 응답 코드를 반환하거나 timeout이나 다른 HTTP 오류가 발생하는 프로젝트 또는 그룹 웹훅은 때때로 실패로 간주되어 일시적으로 비활성화됩니다. 이러한 웹훅은 초기에 1분 동안 비활성화되며, 그 이후의 각 실패 시간에 최대 24시간까지 연장됩니다.

웹훅 수신기에서 더 이상 오류를 반환하지 않는 경우 수동으로 일시적으로 비활성화된 웹훅을 다시 활성화할 수 있습니다.

영구적으로 비활성화된 웹훅

4xx 범위에서 응답 코드를 반환하는 프로젝트 또는 그룹 웹훅은 구성 오류로 간주되어 영구적으로 비활성화됩니다.

이러한 웹훅은 수동으로 다시 활성화될 때까지 비활성화 상태로 유지됩니다.

비활성화된 웹훅 다시 활성화

  • GitLab 15.2에서 webhooks_failed_callout이라는 플래그로 도입되었습니다. 기본적으로 비활성화됩니다.
  • GitLab 15.7에서 일반적으로 사용 가능하게 되었습니다. webhooks_failed_callout 특성 플래그가 제거되었습니다.

일시적으로 또는 영구적으로 비활성화된 웹훅을 수동으로 다시 활성화하려면 테스트 요청을 보냅니다.

테스트 요청이 2xx 범위의 응답 코드를 반환하면 웹훅이 다시 활성화됩니다.

웹훅 테스트

웹훅을 수동으로 트리거하여 올바르게 작동하는지 확인할 수 있습니다. 또한 비활성화된 웹훅을 다시 활성화하기 위해 테스트 요청을 보낼 수도 있습니다.

예를 들어 push 이벤트를 테스트하려면 프로젝트에 적어도 1개의 커밋이 있어야 합니다. 웹훅은 이 커밋을 사용합니다.

참고: 일부 이벤트의 경우 프로젝트 및 그룹 웹훅에 대해 테스트가 지원되지 않습니다. 자세한 내용은 issue 379201을 참조하십시오.

필수 조건:

  • 프로젝트 웹훅을 테스트하려면 프로젝트에 대한 유지자 권한이 있어야 합니다.
  • 그룹 웹훅을 테스트하려면 그룹에 대한 소유자 권한이 있어야 합니다.

웹훅을 테스트하려면:

  1. 프로젝트 또는 그룹에서 왼쪽 사이드바에서 설정 > 웹훅을 선택합니다.
  2. 구성된 웹훅 목록으로 이동합니다.
  3. 테스트 드롭다운 목록에서 테스트할 이벤트 유형을 선택합니다.

웹훅 편집 페이지에서도 웹훅을 테스트할 수 있습니다.

웹훅 테스트

전달 헤더

  • X-Gitlab-Event-UUID 헤더는 GitLab 14.8에서 도입되었습니다.
  • X-Gitlab-Instance 헤더는 GitLab 15.5에서 도입되었습니다.
  • X-Gitlab-Webhook-UUID 헤더는 GitLab 16.2에서 도입되었습니다.
  • Idempotency-Key 헤더는 GitLab 17.4에서 도입되었습니다.

엔드포인트로의 웹훅 요청에는 다음 헤더가 포함됩니다:

헤더 설명 예시
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자에게 전송된 비밀을 회전해야 합니다. 웹훅 페이로드를 비공개로 유지하려면 개인 웹훅 수신기를 작성하십시오.

이러한 공개 도구로는 다음이 있습니다:

  • 임시 HTTPS 엔드포인트를 만들고 들어오는 페이로드를 검사하기 위한 Beeceptor
  • 들어오는 페이로드를 검토하기 위한 Webhook.site
  • 페이로드를 검사 및 디버깅하기 위한 Webhook Tester

GitLab 개발 키트 (GDK)

보다 안전한 개발 환경을 위해 GitLab 개발 키트 (GDK)를 사용하여 로컬에서 GitLab 웹훅을 개발할 수 있습니다. GDK를 사용하면 로컬 GitLab 인스턴스에서 웹훅을 웹훅 수신기로 직접 보낼 수 있습니다. 이 방법을 사용하려면 GDK를 설치하고 구성해야 합니다.

개인 웹훅 수신기 만들기

전제 조건:

  • Ruby가 설치되어 있어야 합니다.

공개 웹훅 수신기에 웹훅 페이로드를 보낼 수 없는 경우, 자체 개인 웹훅 수신기를 만들 수 있습니다.

개인 웹훅 수신기를 만들려면:

  1. 다음 파일을 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
    
  2. 사용하지 않는 포트(예: 8000)를 선택하고 스크립트를 시작하세요.

    ruby print_http_body.rb 8000
    
  3. GitLab에서 웹훅 구성하고 수신기의 URL(예: http://receiver.example.com:8000/)을 추가하세요.
  4. 테스트를 선택하세요. 콘솔에서 유사한 메시지가 표시되어야 합니다.

    {"before":"077a85dd266e6f3573ef7e9ef8ce3343ad659c4e","after":"95cd4a99e93bc4bbabacfa2cd10e6725b1403c60",<SNIP>}
    example.com - - [14/May/2014:07:45:26 EDT] "POST / HTTP/1.1" 200 0
    - -> /
    

이 수신기를 추가하려면 로컬 네트워크로의 요청 허용이 필요할 수 있습니다.

웹훅 본문에 이미지 URL이 표시되는 방법

상대적 이미지 참조는 웹훅 본문에서 절대 URL을 사용하도록 다시 작성됩니다. 예를 들어, 이미지, 병합 요청, 코멘트 또는 위키 페이지에 다음과 같은 이미지 참조가 포함된 경우:

![image](/uploads/$sha/image.png)

다음과 같이:

  • GitLab이 gitlab.example.com에 설치되어 있고,
  • 프로젝트가 example-group/example-project에 있는 경우,

참조는 웹훅 본문에서 다음과 같이 다시 작성됩니다.

![image](https://gitlab.example.com/example-group/example-project/uploads/$sha/image.png)

이미지 URL은:

  • 이미 HTTP, HTTPS 또는 프로토콜 상대적 URL을 가리키는 경우,
  • 링크 라벨과 같은 고급 마크다운 기능을 사용하는 경우에는 다시 작성되지 않습니다.

상호 TLS를 지원하도록 웹훅 구성

Offering: Self-managed

전제 조건:

  • GitLab 관리자여야 합니다.

웹훅을 구성하여 PEM 형식의 클라이언트 인증서를 구성하여 상호 TLS를 지원할 수 있습니다. 이 인증서는 전역적으로 설정되며 TLS 핸드셰이크 중 서버에 제시됩니다. 인증서는 PEM 암호구문으로 보호될 수도 있습니다.

인증서를 구성하려면:

Linux 패키지 (Omnibus)
  1. /etc/gitlab/gitlab.rb를 편집하세요.

    gitlab_rails['http_client']['tls_client_cert_file'] = '<클라이언트 PEM 파일 경로>'
    gitlab_rails['http_client']['tls_client_cert_password'] = '<옵션 비밀번호>'
    
  2. 파일을 저장하고 GitLab을 재구성하세요.

    sudo gitlab-ctl reconfigure
    
Docker
  1. 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'] = '<클라이언트 PEM 파일 경로>'
            gitlab_rails['http_client']['tls_client_cert_password'] = '<옵션 비밀번호>'
    
  2. 파일을 저장하고 GitLab을 다시 시작하세요.

    docker compose up -d
    
Self-compiled (source)
  1. /home/git/gitlab/config/gitlab.yml을 편집하세요.

    production: &base
      http_client:
        tls_client_cert_file: "<클라이언트 PEM 파일 경로>"
        tls_client_cert_password: "<옵션 비밀번호>"
    
  2. 파일을 저장하고 GitLab을 다시 시작하세요.

    # systemd를 실행 중인 시스템의 경우
    sudo systemctl restart gitlab.target
    
    # SysV init를 실행 중인 시스템의 경우
    sudo service gitlab restart
    

웹훅 트래픽에 대한 방화벽 구성

웹훅 트래픽에 대한 방화벽을 구성할 때, 일반적으로 웹훅이 Sidekiq 노드에서 비동기적으로 전송됩니다. 그러나 경우에 따라 웹훅이 UI에서 동기적으로 Rails 노드에서 전송되는 경우가 있습니다. 이는 다음 경우에 해당됩니다.

관련 주제

문제 해결

unable to get local issuer certificate

SSL 검증이 활성화되어 있을 때, GitLab이 웹훅 엔드포인트의 SSL 인증서를 인증할 수 없다는 오류가 발생할 수 있습니다. 일반적으로 이 오류는 루트 인증서가 CAcert.org에서 신뢰할 수 있는 인증서 기관에 의해 발급되지 않았기 때문에 발생합니다.

이 문제를 해결하려면 SSL Checker를 사용하여 오류를 식별하는 것을 고려해보세요. 중간 인증서가 누락되는 것이 확인 실패의 일반적인 원인입니다.

웹훅이 트리거되지 않음

  • GitLab 16.3에서 Silent 모드의 Webhook 트리거가 도입되었습니다.

웹훅이 트리거되지 않는 경우, 다음 사항을 확인하세요: