GitHub Actions 구성
에 대한 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-integration-token 매개변수)에서 GitHubDevOps 생성된 도구의 비밀 토큰입니다. 비밀 토큰에 액세스하려면 (모든 > 도구 > 오케스트레이션 도구)의 ServiceNow 도구 레코드로 GitHub 이동하고 클래식 UI에서 토큰 복사를 선택합니다. |
저장소의 GitHub 워크플로우
YAML 파일을 만들어 리포지토리에서 GitHub 워크플로 구성을 정의합니다.
워크플로우를 정의하는 동안 다음 사항을 고려해야 합니다.
- 리포지토리의 모든 워크플로에는 .yml 또는 .yaml 파일 확장자가 있어야 합니다. 모든 워크플로는
.github/workflows디렉터리 아래에 있어야 하며 GitHub Actions의 워크플로 구문에 정의된 구문을 따라야 합니다. - 워크플로우의 이름은 워크플로우 파일 이름과 일치해야 합니다.
- 작업 탭의 모든 워크플로에 있는 워크플로의 이름은 리포지토리의
.github/workflows디렉터리에 저장된 워크플로와 일치해야 합니다.
- 표시 이름은 모든 작업에 지정되어야 하며 워크플로의 모든 작업에 대해 고유해야 합니다. 작업 이름은 사용자 지정 작업의 스테이지 이름과 일치해야 합니다.
workflow_dispatch이벤트를 사용하여 워크플로우를 수동으로 트리거합니다.
GitHub Actions 의 워크플로우 실행 상세 정보 DevOps
웹후크를 구성한 후에는 워크플로우가 실행되거나 트리거될 때마다 알림 GitHub Actions 이 전송됩니다 ServiceNow DevOps .
워크플로우가 리포지토리에서 GitHub 수동으로 실행되거나 자동으로 트리거되면 다음 세부 정보가 인스턴스로 ServiceNow 전송됩니다.
- workflow_job 웹후크는 ServiceNow 워크플로우가 리포지토리에서 수동으로 실행되거나 자동으로 트리거될 때 작업 상태(큐에 대기 중, in_progress, 완료됨)를 GitHub 인스턴스에 알립니다.
- 인바운드 이벤트는 작업 상태(큐에 대기 중, in_progress, 완료)에 대한 인스턴스에 생성 ServiceNow 되고 in_progress 이벤트는 무시됩니다.
- 큐에 대기 중이고 완료된 인바운드 이벤트가 처리되고, ServiceNow DevOps 워크플로우에 구성된 작업에 대한 파이프라인 단계 및 오케스트레이션 작업이 생성됩니다.
- 파이프라인 실행은 워크플로우 실행에서 실행된 각 작업에 대해 생성된 작업 실행 및 단계 실행 기록과 함께 모든 워크플로우 실행에 대해 생성됩니다.
- 파이프라인 UI를 사용하여 파이프라인 실행 전반에 걸쳐 상호 작용과 결과를 시각화할 수 있습니다.
GitHub 재실행
작업에 대해 GitHub 생성된 변경 요청은 변경 요청이 구현 및 구현 후 단계에 있는 경우 다시 사용됩니다. 예를 들어 파이프라인 실행의 경우 다음과 같습니다.
- 변경 요청이 구현 단계에 있기 전에 작업이 실패하면 실패한 작업을 다시 실행할 때 생성된 변경 요청이 다시 사용되지 않습니다.
- 실패한 작업 또는 모든 작업이 다시 실행되면 새 변경 요청이 생성됩니다.
- 이제 변경 요청이 구현 또는 구현 후 단계에 있을 때 작업이 실패할 경우 실패한 작업 또는 모든 작업을 다시 실행할 때 변경 요청이 다시 사용됩니다.주:작업이 실패하기 전에 변경 요청이 이전 단계에서 이미 구현된 경우 다시 실행하는 동안 파이프라인 실행이 중지되지 않습니다. 변경 요청은 이미 승인되고 구현된 것으로 간주됩니다.
복합 워크플로우
한 워크플로에서 다른 워크플로를 호출하고 변경 단계가 하위 워크플로에 있는 복합 워크플로의 경우 job-name 변경 단계의 매개 변수는 job-name: '<parent-workflow-name> / <child-workflow-name>' 형식이어야 합니다. 여기서 슬래시(/) 앞뒤의 공백은 필수입니다.
GitHub Actions 통합에 대한 DevOps 변경 속도 제한 사항
- GitHub ActionsGitHub 및 환경은 버전 3.3부터 Server에서 GitHub Enterprise 지원됩니다.
- 환경에 대한 GitHub 자세한 내용은 배포에 환경 사용을 참조하세요.
- GitHub 환경은 클라우드에서만 GitHub Enterprise 비공개 리포지토리에서 사용할 수 있습니다.
- 조직의 경우 GitHub 통합을 ServiceNow DevOps 위해 개인용 액세스 토큰이 있는 특정 계정(필요한 조직에 대한 액세스 권한 포함)을 사용하거나 인증 코드 2.0 또는 JWT를 통해 앱을 사용할 GitHub 수도 있습니다.
앱 - JWT를 사용하여 GitHub 도구를 만들려면 별도의 조직을 위해 별도의 도구를 만들어야 합니다.
- 워크플로우 실행을 위해 인스턴스에서 최신 GitHub Actions 검사 결과만 끌어올 수 있습니다.
- ServiceNow DevOps 병렬 작업에는 사용자 지정 작업 또는 환경을 사용한 변경 자동화가 지원되지 않습니다. 병렬 작업의 경우 웹후크 알림 페이로드에는 시퀀스 번호와 병렬로 실행된 작업에 대한 정보가 포함되지 않습니다. 이 제한으로 인해 작업 시퀀스는 (/repos/{owner}/{repo}/actions/runs/{run_id}/jobs) API의 응답에서 반환된 실행 순서에 따라 달라집니다.
- 인스턴스에서 워크플로우 실행을 ServiceNow 일시 중지하고 다시 시작하기 위한 콜백 URL은 배포 게이트 기능에서만 GitHub Actions 지원됩니다. 그러나 배포 게이트와 GitHub Custom Action을 통해 변경 내용을 만들 수 있습니다.
- 인스턴스에서 ServiceNow 도구를 만드는 GitHub 사용자는 환경에 대한 GitHub 워크플로우를 승인하는 검토자여야 합니다.