지속적 통합 설정
푸시와 모든 변경 요청 시 무엇을 실행할지 결정하고, 프로젝트 포지가 이해하는 구문으로 작성합니다. 이 파일의 결정 사항은 포지에 독립적입니다: 생태계를 감지하고, 실행해야 할 항목을 결정하며, 매트릭스를 선택하고, 캐싱을 결정합니다. 이러한 결정을 표현하는 구문은 포지에 종속적이므로, GitHub Actions의 경우 references/github-actions.md에, GitLab CI/CD의 경우 references/gitlab.md에 위치합니다. 구성을 작성하기 전에 해당 참조 파일을 읽으십시오; 한 포지의 키워드를 다른 포지의 키워드로 번역하여 작성하지 마십시오. 두 포지는 트리거, 매트릭스, 캐싱에 대해 서로 다른 구조를 가지고 있기 때문입니다.
범위
이 스킬은 실행될 항목을 소유합니다: 어떤 검사가 실행되는지, 어떤 트리거에서, 어떤 버전에 대해, 어떤 캐싱을 사용하는지. 이 스킬이 작성하는 워크플로 및 파이프라인 파일은 다른 두 스킬과 공유하며, 이들 간의 경계는 규칙 영역에 있으며 파일에 대한 설명이 아닙니다.
아래 CI 규칙(R-CI-*)은 여기에 속합니다. SEC 규칙(동일 파일의 보안 태세, 예: 고정된 액션 SHA, 최소 권한, 종속성 업데이터, 브랜치 보호, 고정된 이미지)은 oss-harden에 속합니다. REL 규칙(신뢰할 수 있는 퍼블리싱, 출처 증명, 승인 게이트를 사용하여 빌드된 아티팩트를 레지스트리에 게시)은 oss-publish에 속합니다. 이 스킬을 사용하는 동안에는 permissions: 블록을 추가하거나, SHA를 고정하거나, 브랜치 보호를 구성하거나, 게시 작업을 작성하지 마십시오; 프로젝트에 필요하다는 점을 기록하고 해당 작업을 소유하는 스킬에 넘기십시오.
빌드된 정적 사이트를 포지의 자체 Pages 호스팅에 배포하는 것도 푸시 시 실행되는 항목이므로, 레지스트리 릴리스를 소유하는 oss-publish가 아닌 여기에 남습니다. 어떤 규칙도 이를 요구하지 않습니다: 프로젝트는 사이트가 있기 때문에 사이트를 게시하므로, 저장소가 사이트를 빌드하고 사용자가 배포를 요청하는 경우에만 작성됩니다.
원칙
단계, 비밀, 또는 구성 값을 추가하기 전에 모든 것을 확인하십시오: 실제 저장소를 읽고 추측하지 마십시오. 불확실한 경우에는 그럴듯한 답을 만들어내지 말고 질문하십시오.
파이프라인 내부에서 셸 로직을 작성하는 대신 프로젝트 자체의 자동화를 호출하십시오. jest --coverage --ci 대신 npm test를 실행하는 단계는 파이프라인과 기여자의 랩톱이 동일한 명령을 실행하도록 유지하며, 이는 R-CI-02가 확인하는 사항입니다. 그러한 자동화가 존재하지 않는 경우, 프로젝트에 추가할지 아니면 인라인 명령으로 대체할지 질문하십시오.
저장소에 이미 테스트, Dockerfile 또는 파이프라인이 포함되어 있더라도 정책 선택 사항을 추측하지 말고 제시하십시오. 변경 요청 시 무엇을 실행할지, 릴리스 빌드를 트리거할 항목, 배포가 어떻게 이루어질지는 사용자가 결정하는 사항입니다; 코드는 가능한 것만 알려줄 뿐, 원하는 것을 알려주지 않습니다.
프로세스
1단계: 포지 감지
기존의 .github/workflows/ 디렉토리나 .gitlab-ci.yml 파일을 찾고, git 원격 저장소에서 github.com 또는 gitlab 호스트를 확인하거나, 두 신호가 모두 없으면 직접 질문하십시오. 이는 6단계와 7단계에서 어떤 참조 파일을 사용할지 결정합니다. 사용자가 명시적으로 포지를 언급하는 경우, 저장소에서 발견된 어떤 신호보다 그 정보를 신뢰하십시오.
2단계: 저장소 분석
소스 파일과 패키지 매니페스트에서 언어와 런타임을 식별하고, 프로젝트가 지원한다고 명시한 버전 범위를 기록하십시오; R-CI-03에 따라 4단계의 매트릭스는 지원되는 가장 오래된 버전과 가장 최신 버전을 포함하여 모든 범위를 다루어야 합니다.
프로젝트가 이미 정의한 모든 적용 가능한 린트, 테스트, 타입체크, 빌드 명령어(패키지 매니저 스크립트, Makefile, Rakefile, tox 또는 just와 같은 도구 포함)를 찾아 인수와 부작용을 충분히 숙지하십시오. 누락된 검사 클래스를 만들어내지 마십시오: 문서 저장소에는 빌드가 없을 수 있고, 작은 스크립트에는 린터가 없을 수 있습니다. 저장소에 CONTRIBUTING 가이드가 있는 경우, 해당 명령어와 프로젝트 자동화가 일치해야 합니다; 충돌이 있으면 CI에 복사하기 전에 해결하십시오.
기존 CI 구성을 변경하기 전에 읽어서 확장할지 또는 교체할지 결정하십시오.
프로젝트가 커밋하는 모든 잠금 파일(예: package-lock.json, Gemfile.lock, poetry.lock, Cargo.lock)과 각 설치 명령어가 안전하게 재사용할 수 있는 패키지 매니저 다운로드 캐시를 식별하십시오. 설치된 종속성 디렉토리를 캐시로 가정하지 마십시오.
.env.example을 찾고 소스에서 필요한 환경 변수를 검색하여, 비밀을 필요로 하는 단계가 실행 실패 후가 아니라 생성 전에 식별되도록 하십시오.
3단계: 결과 제시 및 질문
2단계에서 찾은 내용을 요약한 후, 코드만으로는 답할 수 없는 선택 사항에 대해 질문하십시오: 풀 또는 병합 요청 시 무엇을 실행할지, 릴리스 빌드를 트리거할 항목, 기존 CI를 확장할지 교체할지. 이 프로젝트에 적용되는 것만 질문하십시오; Dockerfile이 없는 프로젝트에는 레지스트리에 대한 질문을 하지 않습니다.
2단계에서 정적 사이트를 생성하는 빌드를 발견한 경우, 이를 배포해야 하는지, 그리고 어디에 배포해야 하는지 질문하십시오. 사이트는 검사로만 빌드되고 게시되지 않을 수 있으므로, 정적 빌드를 배포에 대한 동의로 간주하지 말고 질문으로 처리하십시오.
4단계: 매트릭스 선택
2단계에서 식별된 지원되는 릴리스 라인에서 버전 매트릭스를 구축하되, 단일 고정 버전이 아닌 모든 유지보수되는 주요 또는 부 minor 릴리스 라인을 포함하십시오. 명시된 지원 범위가 없는 프로젝트는 발명된 매트릭스 대신 단일 버전 파이프라인을 받습니다; 매니페스트가 명시하지 않은 지원 주장을 만들어내지 마십시오. 범위가 연속적이고 프로젝트가 지원하지 않을 릴리스 라인을 포함하는 경우, 조용히 하위 집합을 테스트하는 대신 선언된 범위를 수정하십시오.
5단계: 캐싱 결정
패키지 매니저 다운로드 데이터 또는 도구의 공식 문서에서 재사용해도 안전하다고 명시한 다른 디렉토리만 캐싱하십시오. 감지된 패키지 매니저를 지원하고 잠금 파일을 해싱하는 포지의 공식 런타임 설정 액션을 선호하십시오. 그렇지 않으면 잠금 파일과 내용을 변경하는 모든 호환성 경계(예: 운영 체제, 아키텍처, 런타임, 패키지 매니저)에 대해 명시적 캐시 키를 설정하십시오. 폴백 키는 선택 사항이며 이러한 경계 중 하나를 넘지 않아야 합니다. 잠금 파일이나 재사용 가능한 다운로드 캐시가 없는 프로젝트는 캐시 단계를 받지 않습니다.
6단계: 구성 작성
1단계에서 선택한 포지에 대한 참조 파일을 열고 해당 구문을 정확히 따르십시오. 두 참조 파일 모두 기본 브랜치 푸시 및 모든 변경 요청 시 트리거(R-CI-01), 모든 작업에 대한 타임아웃 및 동일 브랜치에서 대체된 실행 취소(R-CI-05), 5단계의 캐시 결정(R-CI-04)을 다룹니다. 또한 Pages 배포 섹션을 포함하지만, 3단계에서 프로젝트가 이를 원한다고 확인된 경우에만 사용됩니다. 어느 참조 파일도 권한, SHA 고정 또는 퍼블리싱을 다루지 않습니다; 이들은 여기서 작성하는 파일에서 제외됩니다.
7단계: 제시 전 검증
가능한 경우 포지의 자체 검증기를 사용하여 구성이 구문적으로 유효한지 확인하고, 호출하는 모든 명령어가 존재하며 로컬에서 동일한 순서로 성공하는지 확인하십시오. GitLab의 경우 포함된 구성을 확장한 CI Lint를 사용하십시오. GitHub의 경우 Actions 편집기에서 워크플로를 검사하거나, 사용자가 외부 변경을 승인한 경우 브랜치에 푸시하십시오; 일반 YAML 파서는 GitHub 표현식이나 워크플로 의미를 검증할 수 없습니다. 파이프라인에 필요한 비밀 목록을 각 비밀을 추가하는 명령어와 함께 나열하되, 해당 명령어를 실행하지 마십시오. 매트릭스가 모든 지원되는 릴리스 라인과 일치하는지, 모든 작업에 타임아웃이 있으며 안전한 경우 대체된 실행 취소에 참여하는지 확인하십시오.
8단계: 결과 제시
생성된 파일, 감지 및 결정된 사항에 대한 간단한 요약, 구성해야 할 비밀 목록, 그리고 저장소 또는 프로젝트 수준에서 사용자가 설정해야 할 항목(예: 브랜치 보호 또는 환경 승인자)을 표시하고, 해당 항목을 소유하는 스킬을 명명하여 여기서 시도하지 마십시오.
이 스킬이 소유하는 규칙
- R-CI-01: CI는 기본 브랜치에 대한 모든 푸시와 모든 변경 요청 시 실행됩니다.
- R-CI-02: CI는 기여 가이드가 인간에게 제공하는 것과 동일한 린트, 테스트 및 빌드 명령어를 실행합니다.
- R-CI-03: 테스트 매트릭스는 프로젝트가 지원한다고 명시한 모든 런타임 버전을 포함합니다.
- R-CI-04: 종속성 캐시는 잠금 파일을 키로 사용합니다.
- R-CI-05: 모든 작업에는 타임아웃이 있으며, 동일 브랜치에 대한 대체된 실행은 취소됩니다.