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 매개변수)에서 DevOps 생성된 도구의 GitHub 비밀 토큰입니다. 비밀 토큰에 액세스하려면 (모든 > 도구 > 오케스트레이션 도구)에서 ServiceNow 도구 기록으로 GitHub 이동하여 클래식 UI에서 토큰 복사를 선택합니다. 주: 성공적인 인증을 보장하려면 SN_DEVOPS_INTEGRATION_TOKEN 비밀을 새 토큰으로 수동으로 업데이트해야 합니다. |
리포지토리의 GitHub 워크플로우
YAML 파일을 생성하여 리포지토리에서 워크플로우 구성을 정의합니다 GitHub .
워크플로우를 정의하는 동안 다음 사항을 고려해야 합니다.
- 리포지토리의 모든 워크플로우에는 .yml 또는 .yaml 파일 확장명이 있어야 합니다. 모든 워크플로는
.github/workflows디렉터리에 있어야 하며 GitHub Actions에 대한 워크플로 구문에 정의된 구문을 따라야 합니다. - 워크플로우 이름은 워크플로우 파일 이름과 일치해야 합니다.
- 작업 탭의 모든 워크플로우에 있는 워크플로우 이름은 리포지토리의
.github/workflows디렉터리에 저장된 워크플로우와 일치해야 합니다.
- 모든 작업에 대해 표시 이름을 지정해야 하며 워크플로우의 모든 작업에 대해 고유해야 합니다. 작업 이름은 사용자 지정 작업의 스테이지 이름과 일치해야 합니다.
workflow_dispatch이벤트를 사용하여 워크플로우를 수동으로 트리거합니다.
GitHub Actions 의 워크플로우 실행 상세 정보 DevOps
웹후크를 구성하면 워크플로우가 실행되거나 트리거될 때마다 의 GitHub Actions 알림이 전송 ServiceNow DevOps 됩니다.
워크플로우가 수동으로 실행되거나 리포지토리에서 GitHub 자동으로 트리거되면 다음 세부 정보가 인스턴스로 ServiceNow 전송됩니다.
- workflow_job 웹후크는 워크플로우가 수동으로 실행되거나 리포지토리에서 GitHub 자동으로 트리거될 때 인스턴스에 ServiceNow 작업 상태(큐에 대기 중, in_progress됨, 완료됨)를 알립니다.
- 인바운드 이벤트는 작업 상태(큐에 대기 중, in_progress 및 완료됨)에 대한 인스턴스에 ServiceNow 생성되고 in_progress 이벤트는 무시됩니다.
- 큐에 대기 중인 완료된 인바운드 이벤트가 처리되고 ServiceNow DevOps 워크플로우에 구성된 작업에 대해 파이프라인 단계 및 오케스트레이션 작업이 생성됩니다.
- 파이프라인 실행은 워크플로우 실행에서 실행되는 각 작업에 대해 생성된 작업 실행 및 단계 실행 기록과 함께 모든 워크플로우 실행에 대해 생성됩니다.
- 파이프라인 UI를 사용하여 파이프라인 실행 전반의 상호작용과 결과를 시각화할 수 있습니다.
GitHub 재실행
작업에 대해 GitHub 생성된 변경 요청은 변경 요청이 구현 및 구현 후 단계에 있는 경우 다시 사용됩니다. 예를 들어 파이프라인 실행의 경우 다음을 수행합니다.
- 변경 요청이 구현 단계에 들어가기 전에 작업이 실패하면 실패한 작업을 다시 실행할 때 생성된 변경 요청이 다시 사용되지 않습니다.
- 실패한 작업이나 모든 작업이 다시 실행되면 새 변경 요청이 생성됩니다.
- 이제 변경 요청이 구현 또는 구현 후 단계에 있을 때 작업이 실패하면 실패한 작업 또는 모든 작업을 다시 실행할 때 변경 요청이 다시 사용됩니다.주:작업이 실패하기 전에 이전 단계에서 변경 요청이 이미 구현된 경우 재실행 중에 파이프라인 실행이 중지되지 않습니다. 변경 요청은 이미 승인되고 구현된 것으로 간주됩니다.
복합 워크플로우
한 워크플로우가 다른 워크플로우를 호출하고 변경 단계가 하위 워크플로우에 있는 복합 워크플로우의 경우, job-name 변경 단계의 매개변수는 job-name: '<parent-job-name> / <child-job-name>' 형식이어야 합니다. 여기서 슬래시(/) 앞뒤의 공백은 필수입니다.
GitHub Actions 통합에 대한 DevOps 변경 속도 제한 사항
- GitHub Actions 및 GitHub 환경은 버전 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 사용자 지정 작업을 통해 모두 가능합니다.
- 인스턴스에서 ServiceNow 도구를 생성하는 GitHub 사용자는 검토자여야 환경에 대한 워크플로우를 승인할 수 있습니다.GitHub