GitHub Actions 구성

  • 릴리스 버전: Zurich
  • 업데이트 날짜 2025년 07월 31일
  • 소요 시간: 5분

    • 비밀, 워크플로우 및 제한 사항과 같은 구성 정보 GitHub Actions입니다.

    의 비밀 GitHub Actions

    리포지토리 또는 GitHub 조직에 비밀(자격 증명)을 GitHub 생성합니다. 비밀은 조직 또는 리포지토리에서 만드는 환경 변수(암호화됨)입니다. 이러한 비밀은 워크플로에서 GitHub Actions 사용할 수 있습니다. 자세한 내용은 암호화된 비밀을 참조하세요.

    비밀 설명
    SN_INSTANCE_URL ServiceNow 인스턴스 URL입니다. 예: https://<instance_name>.service-now.com.
    SN_ORCHESTRATION_TOOL_ID 인스턴스에서 생성된 ServiceNow 도구에 대한 GitHub Sys_id입니다.
    SN_DEVOPS_INTEGRATION_TOKEN 에서 DevOps 생성된 도구의 비밀 토큰 GitHub 입니다(devops-integration-token 매개변수). 비밀 토큰에 액세스하려면 (모든 > 도구 > 오케스트레이션 도구)의 ServiceNow 도구 기록으로 이동하고 GitHub 클래식 UI에서 토큰 복사를 선택합니다.

    리포지토리의 GitHub 워크플로우

    YAML 파일을 생성하여 리포지토리에서 GitHub 워크플로우 구성을 정의합니다.

    워크플로우를 정의하는 동안 다음 사항을 고려해야 합니다.
    • 리포지토리의 모든 워크플로우에는 .yml 또는 .yaml 파일 확장자가 있어야 합니다. 모든 워크플로는 .github/workflows 디렉터리에 있어야 하며 GitHub Actions에 대한 워크플로 구문에 정의된 구문을 따라야 합니다.

      GitHub Actions 탭의 워크플로

    • 워크플로우의 이름은 워크플로우 파일 이름과 일치해야 합니다.

      워크플로우 이름은 파일 이름과 일치해야 합니다.

    • 작업 탭의 모든 워크플로 아래에 있는 워크플로의 이름은 리포지토리의 .github/workflows 디렉터리에 저장된 워크플로와 일치해야 합니다.

      작업 탭에 워크플로우 파일 배치

    • 표시 이름은 모든 작업에 지정되어야 하며 워크플로우의 모든 작업에 대해 고유해야 합니다. 작업 이름은 사용자 지정 작업의 스테이지 이름과 일치해야 합니다.

      사용자 지정 작업의 작업 이름

    • workflow_dispatch 이벤트를 사용하여 워크플로우를 수동으로 트리거합니다.

      이벤트를 사용하여 워크플로우를 수동으로 트리거

    GitHub Actions 의 워크플로우 실행 상세 정보 DevOps

    웹후크를 구성한 후에는 워크플로우가 실행되거나 트리거될 때마다 알림이 GitHub Actions 전송됩니다 ServiceNow DevOps .

    워크플로우가 리포지토리에서 GitHub 수동으로 실행되거나 트리거되면 다음 상세 정보가 인스턴스로 ServiceNow 전송됩니다.
    • workflow_job 웹후크는 워크플로우가 리포지토리에서 수동으로 실행되거나 자동으로 트리거될 때 작업의 상태(큐에 대기 중, in_progress, 완료됨)를 GitHub 인스턴스에 알립니다ServiceNow.
    • 작업 상태(큐에 대기 중, in_progress 및 완료됨)에 대한 인바운드 이벤트가 인스턴스에 생성 ServiceNow 되고 in_progress 이벤트는 무시됩니다.
    • 대기 중이고 완료된 인바운드 이벤트가 처리되고 ServiceNow DevOps 워크플로우에 구성된 작업에 대한 파이프라인 단계 및 오케스트레이션 작업이 생성됩니다.
    • 파이프라인 실행은 워크플로우 실행에서 실행된 각 작업에 대해 생성된 작업 실행 및 단계 실행 기록과 함께 모든 워크플로우 실행에 대해 생성됩니다.
    • 파이프라인 UI를 사용하여 파이프라인 실행 전반에 걸친 상호 작용과 결과를 시각화할 수 있습니다.

    GitHub 재실행

    변경 요청이 구현 및 사후 구현 단계에 있는 경우 작업에 대해 GitHub 생성된 변경 요청이 다시 사용됩니다. 예를 들어, 파이프라인 실행의 경우:
    • 변경 요청이 구현 단계에 들어가기 전에 작업이 실패하면 실패한 작업을 다시 실행할 때 생성된 변경 요청이 다시 사용되지 않습니다.
    • 실패한 작업 또는 모든 작업을 다시 실행하면 새 변경 요청이 생성됩니다.
    • 이제 변경 요청이 구현 또는 구현 후 단계에 있을 때 작업이 실패하면 실패한 작업 또는 모든 작업이 다시 실행될 때 변경 요청이 다시 사용됩니다.
      주:
      작업이 실패하기 전에 이전 단계에서 변경 요청이 이미 구현된 경우 다시 실행하는 동안 파이프라인 실행이 중지되지 않습니다. 변경 요청은 이미 승인되고 구현된 것으로 간주됩니다.

    복합 워크플로우

    한 워크플로우가 다른 워크플로우를 호출하고 변경 단계가 하위 워크플로우에 있는 복합 워크플로우의 경우, job-name 변경 단계의 매개변수는 job-name: '<parent-job-name> / <child-job-name>' 형식이어야 합니다. 여기서 슬래시(/) 앞뒤의 공백은 필수입니다.

    그림 1. 하위 워크플로우의 job-name 매개변수 예
    샘플 job-name 매개변수.

    GitHub ActionsDevOps 변경 속도 통합 제한 사항

    • GitHub Actions 및 GitHub 환경은 버전 3.3부터 서버에서 지원됩니다 GitHub Enterprise .
      • 환경에 대한 GitHub 자세한 내용은 배포를 위한 환경 사용을 참조하세요.
      • GitHub 환경은 클라우드의 GitHub Enterprise 개인 리포지토리에서만 사용할 수 있습니다.
    • 조직의 경우 GitHub 통합을 위해 개인 액세스 토큰이 있는 특정 계정(필요한 조직에 대한 액세스 권한 포함)을 ServiceNow DevOps 사용하거나 인증 코드 2.0 또는 JWT를 통해 앱을 사용할 GitHub 수도 있습니다.

      Apps - JWT를 사용하여 GitHub 도구를 생성하려면 별도의 구성을 위해 별도의 도구를 생성해야 합니다.

    • 워크플로우 실행을 위해 인스턴스에서 최신 GitHub Actions 스캔 결과만 끌어올 수 있습니다.
    • ServiceNow DevOps 사용자 지정 작업 또는 환경을 사용한 자동화 변경은 병렬 작업에 지원되지 않습니다. 병렬 작업의 경우 웹후크 알림 페이로드에는 시퀀스 번호와 병렬로 실행되는 작업에 대한 정보가 포함되지 않습니다. 이러한 제한으로 인해 작업 시퀀스는 (/repos/{owner}/{repo}/actions/runs/{run_id}/jobs) API의 응답에서 반환되는 실행 순서에 따라 달라집니다.
    • 인스턴스에서 워크플로우 실행을 ServiceNow 일시 중지하고 재개하기 위한 콜백 URL은 배포 게이트 기능에서만 GitHub Actions 지원됩니다. 그러나 배포 게이트와 GitHub 사용자 지정 작업을 통해 변경 만들기를 만들 수 있습니다.
    • 인스턴스에 도구를 ServiceNow 만드는 GitHub 사용자가 환경에 대한 GitHub 워크플로우를 승인하려면 검토자여야 합니다.