사전 빌드 구성

리포지토리의 특정 분기와 특정 개발 컨테이너 구성 파일의 조합에 대한 사전 빌드 구성을 설정할 수 있습니다.

사전 빌드 사용 부모 분기에서 만든 모든 분기도 일반적으로 동일한 개발 컨테이너 구성에 대한 사전 빌드를 가져옵니다. 이는 부모 분기와 동일한 개발 컨테이너 구성을 사용하는 자식 분기의 사전 빌드가 대부분 동일하므로 개발자가 해당 분기에서 더 빠른 codespace 생성 시간을 활용할 수 있기 때문입니다. 자세한 내용은 "개발 컨테이너 소개"을(를) 참조하세요.

일반적으로 분기에 대한 사전 빌드를 구성할 때 여러 시스템 유형에 대해 사전 빌드를 사용할 수 있습니다. 그러나 리포지토리가 32GB보다 큰 경우 이러한 스토리지가 32GB로 제한되므로 2코어 및 4코어 머신 유형에는 사전 빌드를 사용할 수 없습니다.

필수 조건

GitHub Actions을(를) 사용하여 사전 빌드를 만듭니다. 따라서 사전 빌드를 구성하는 리포지토리에 대해 반드시 GitHub Actions을(를) 사용하도록 설정해야 합니다. 자세한 내용은 "리포지토리에 대한 GitHub Actions 설정 관리"을(를) 참조하세요.

개인 계정이 소유한 모든 리포지토리에서 사전 빌드를 설정할 수 있습니다. 사전 빌드는 청구 가능한 요금이 발생하는 스토리지 공간이나 개인 계정이 소유한 리포지토리에 포함되는 월별 스토리지 중 일부를 사용합니다.

조직이 소유한 리포지토리의 경우 조직이 GitHub Team 또는 GitHub Enterprise 플랜을 사용한다면 사전 빌드를 설정할 수 있습니다. 추가적으로 조직 계정 또는 부모 엔터프라이즈에서 결제 방법을 추가하고 GitHub Codespaces의 지출 한도를 설정해야 합니다. 자세한 내용은 "GitHub Codespaces의 지출 한도 관리" 및 "GitHub의 플랜"을 참조하세요.

사전 빌드 구성

1. GitHub.com에서 리포지토리의 기본 페이지로 이동합니다.

2. 리포지토리 이름 아래에서 Settings(설정)를 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.

   

3. 사이드바의 “코드 및 자동화” 섹션에서 Codespaces 를 클릭합니다.

4. 페이지의 "사전 빌드 구성" 섹션에서 사전 빌드 설정을 클릭합니다.

   

5. 사전 빌드를 설정할 분기를 선택합니다.

   

   참고: 사전 빌드 사용 기본 분기에서 만든 모든 분기도 일반적으로 동일한 개발 컨테이너 구성에 대한 사전 빌드를 가져옵니다. 예를 들어 리포지토리의 기본 분기에서 개발 컨테이너 구성 파일에 대해 사전 빌드를 사용하도록 설정하면 대부분의 경우 기본 분기를 기반으로 한 분기도 동일한 개발 컨테이너 구성에 대한 사전 빌드를 가져옵니다.

6. 필요한 경우 표시되는 구성 파일 드롭다운 메뉴에서 사전 빌드에 사용할 devcontainer.json 구성 파일을 선택합니다. 자세한 내용은 "개발 컨테이너 소개"을(를) 참조하세요.

   

7. 사전 빌드의 업데이트를 자동으로 트리거하는 방법을 선택합니다.

   • 모든 푸시(기본 설정) - 이 설정을 사용하면 지정된 분기에 수행되는 모든 푸시마다 사전 빌드가 업데이트됩니다. 이렇게 하면 사전 빌드에서 생성된 codespace에 최근 추가되거나 업데이트된 종속성을 포함하여 항상 최신 codespace 구성이 포함됩니다.

   • 구성 변경 시 - 이 설정을 사용하면 다음 파일이 변경될 때마다 사전 빌드가 업데이트됩니다.

     • .devcontainer/devcontainer.json

       참고: 사전 빌드 업데이트는 .devcontainer의 하위 디렉터리 내에 있는 devcontainer.json 파일에 대한 변경 내용에 의해 트리거되지 않습니다.

     • .devcontainer/devcontainer.json 파일의 build.dockerfile 속성에서 참조되는 Dockerfile

     이렇게 하면 사전 빌드에서 codespace를 생성할 때 리포지토리에 대한 개발 컨테이너 구성 파일의 변경 내용이 사용됩니다. 사전 빌드를 업데이트하는 GitHub Actions 워크플로가 덜 자주 실행되므로 이 옵션은 GitHub Actions 시간(분)을 더 적게 사용합니다. 그러나 이 옵션은 codespace에 항상 최근에 추가되거나 업데이트된 종속성이 포함되어 있다고 보장할 수 없으므로 codespace를 만든 후에 수동으로 추가하거나 업데이트해야 할 수 있습니다.

   • 예약됨 - 이 설정을 사용하면 사용자가 정의한 사용자 지정 일정에 따라 사전 빌드를 업데이트할 수 있습니다. 이렇게 하면 GitHub Actions 시간(분)을 줄일 수 있지만 이 옵션으로 최신 개발 컨테이너 구성 변경 내용을 사용하지 않는 codespace가 생성될 수 있습니다.

   

8. 필요에 따라 지정된 지역에서만 사용할 수 있는 사전 빌드를 만들기 위해서 특정 지역에만 사용할 수 있도록 사전 빌드 축소를 선택합니다. 사전 빌드를 사용할 지역을 선택합니다.

   기본적으로 사전 빌드는 사용 가능한 모든 지역에 만들어지고, 사전 빌드마다 스토리지 요금이 발생합니다.

   

   참고:

   • 각 지역의 사전 빌드에는 개별 스토리지 요금이 발생합니다. 따라서 사전 빌드가 사용될 것으로 알고 있는 지역에 대해서만 사전 빌드를 사용하도록 설정해야 합니다. 자세한 내용은 "GitHub Codespaces 청구 관련 정보"을(를) 참조하세요.
   • 개발자는 GitHub Codespaces에 대한 기본 지역을 설정할 수 있으며 이를 통해 더 적은 수의 지역에 대해 사전 빌드를 사용하도록 설정할 수 있습니다. 자세한 내용은 "Github Codespaces의 기본 지역 설정"을(를) 참조하세요.

9. 필요한 경우 템플릿 기록에서 보존할 사전 빌드 버전 수를 설정합니다. 1에서 5 사이의 숫자를 입력할 수 있습니다. 저장된 버전의 기본 개수는 2입니다. 즉, 최신 사전 빌드와 바로 전 버전만 저장됩니다.

   

   사전 빌드 트리거 설정에 따라 각각의 푸시 또는 개발 컨테이너 구성 변경에 따라 사전 빌드가 변경됩니다. 이전 버전의 사전 빌드를 유지하면 현재 사전 빌드와 다른 개발 컨테이너 구성을 사용하여 이전 커밋에서 사전 빌드를 만들 수 있습니다. 이 설정을 사용하면 보존된 버전 수를 적합한 수준으로 설정할 수 있습니다.

   사전 빌드 버전 수를 1로 저장하도록 설정한 경우 GitHub Codespaces은(는) 사전 빌드의 최신 버전만 저장하고 템플릿이 업데이트될 때마다 이전 버전을 삭제합니다. 즉, 이전의 개발 컨테이너 구성으로 돌아가면 사전 빌드된 codespace는 표시되지 않습니다.

   유지되는 각 사전 빌드 버전에 대해 스토리지 비용이 발생합니다. 예를 들어 4개 지역에서 사전 빌드를 생성하고 2개의 버전을 유지하는 경우 최대 8개의 사전 빌드에 대한 스토리지 요금이 청구됩니다. 요금 청구에 대한 자세한 내용은 "GitHub Codespaces 청구 관련 정보"을(를) 참조하세요.

10. 필요한 경우 이 구성에 대해 사전 빌드 워크플로 실행이 실패할 때 알릴 사용자 또는 팀을 추가합니다. 사용자 이름, 팀 이름 또는 전체 이름을 입력한 다음 목록에 이름을 추가하려면 이름을 클릭할 수 있습니다. 추가한 사용자나 팀은 사전 빌드 오류가 발생할 때 추가 조사에 도움이 되는 워크플로 실행 로그 링크를 포함하는 메일을 받게 됩니다.

    

    참고: 개인 설정에서 실패한 Action 워크플로에 대한 알림을 사용하도록 설정한 실패한 사전 빌드에 대한 알림만 받습니다. 자세한 내용은 "알림 구성"을(를) 참조하세요.

11. 필요에 따라 페이지 아래쪽에서 고급 옵션 표시를 클릭합니다.

    

    "고급 옵션" 섹션에서 사전 빌드 최적화 사용 안 함을 선택하면 최신 사전 빌드 워크플로가 실패했거나 현재 실행 중인 경우 codespace가 사전 빌드 없이 만들어집니다. 자세한 내용은 "사전 빌드 문제 해결"을(를) 참조하세요.

12. 만들기를 클릭합니다.

    리포지토리에 대한 개발 컨테이너 구성에서 다른 리포지토리에 액세스하기 위한 권한을 지정하는 경우 권한 부여 페이지가 표시됩니다. devcontainer.json 파일에서 이것이 지정되는 방법에 대한 자세한 내용은 "Codespace 내의 다른 리포지토리에 대한 액세스 관리"을(를) 참조하세요.

    요청한 사용 권한의 세부 정보를 보려면 을 클릭합니다.

    

    사전 빌드 생성에 대해 이러한 사용 권한을 부여하려면 권한 부여하고 계속하기를 클릭합니다. 또는 권한 부여 건너뛰고 계속하기를 클릭해도 되지만 이렇게 하면 사전 빌드 결과로 만들어진 codespace가 제대로 작동하지 않을 수 있습니다.

    참고: 이 사전 빌드를 사용하여 codespace를 만드는 사용자에게도 이러한 권한을 부여하라는 메시지가 표시됩니다.

사전 빌드 구성을 만들면 리포지토리 설정의 GitHub Codespaces 페이지에 나열됩니다. GitHub Actions 워크플로는 큐에 대기된 다음, 지정한 지역에서 선택한 분기 및 개발 컨테이너 구성 파일에 따라 사전 빌드를 만들기 위해 실행됩니다.

사전 빌드 구성을 편집하고 삭제하는 방법에 대한 자세한 내용은 "사전 빌드 관리"을(를) 참조하세요.

환경 변수 구성

사전 빌드 프로세스가 개발 환경을 만드는 데 필요한 환경 변수에 액세스할 수 있도록 하려면 Codespaces 리포지토리 비밀 또는 Codespaces 조직 비밀로 설정할 수 있습니다. 이 방법으로 만든 비밀은 이 리포지토리에서 codespace를 만드는 모든 사용자가 액세스할 수 있습니다. 자세한 내용은 "리포지토리 또는 조직에 대한 개발 환경 비밀 관리"을(를) 참조하세요.

사전 빌드에서는 사용자 환경을 빌드하는 동안 사용자 수준 비밀을 사용할 수 없습니다. codespace가 만들어진 후에야 사용자 수준 비밀을 사용할 수 있기 때문입니다.

사전 빌드에 포함할 시간이 오래 걸리는 작업 구성

devcontainer.json에서 onCreateCommand 및 updateContentCommand 명령을 사용하여 사전 빌드 생성의 일부로 시간이 오래 걸리는 프로세스를 포함할 수 있습니다. 자세한 내용은 Visual Studio Code 설명서, "devcontainer.json 참조"를 참조하세요.

onCreateCommand은(는) 사전 빌드가 만들어질 때 한 번만 실행되는 반면 updateContentCommand은(는) 사전 빌드를 만들 때와 후속 업데이트마다 실행됩니다. 증분 빌드는 프로젝트의 소스를 나타내고 모든 사전 빌드 업데이트에 포함되어야 하므로 updateContentCommand에 포함되어야 합니다.

추가 참고 자료

• "사전 빌드에서 다른 리포지토리에 액세스할 수 있도록 허용"
• "사전 빌드 문제 해결"