AWS CodeBuild
사용 설명서 (API 버전 2016-10-06)

CodeBuild의 빌드 사양 참조

이 단원에서는 빌드 사양(build spec) 파일에 대한 중요한 참조 정보를 제공합니다. 빌드 사양은 CodeBuild가 빌드를 실행하는 데 사용하는 YAML 형식의 빌드 명령 및 관련 설정의 모음입니다. 소스 코드의 일부로 빌드 사양을 포함할 수 있으며, 빌드 프로젝트를 생성할 때 빌드 사양을 정의할 수도 있습니다. 빌드 사양의 작동 방식에 대한 자세한 정보는 CodeBuild 작동 방식 단원을 참조하십시오.

빌드 사양 파일 이름 및 스토리지 위치

빌드 사양을 소스 코드의 일부로 포함시키는 경우, 기본적으로 빌드 사양 파일의 이름은 buildspec.yml이어야 하며 소스 디렉터리의 루트에 있어야 합니다.

기본 빌드 사양 파일 이름과 위치를 재정의할 수 있습니다. 예를 들어 다음을 수행할 수 있습니다.

  • 동일한 리포지토리의 다른 빌드에 대해 buildspec_debug.ymlbuildspec_release.yml과 같은 다른 빌드 사양 파일을 사용합니다.

  • config/buildspec.yml과 같은 빌드 사양 파일을 소스 디렉터리의 루트가 아닌 다른 위치에 저장합니다.

빌드 사양 파일의 이름에 관계없이 빌드 프로젝트에 대해 하나의 빌드 사양만 지정할 수 있습니다.

기본 빌드 사양 파일 이름, 위치 또는 두 항목 모두를 재정의하려면 다음 작업 중 하나를 수행합니다.

  • AWS CLI create-project 또는 update-project 명령을 실행하여 buildspec 값을 내장 환경 변수 CODEBUILD_SRC_DIR의 값에 상대적인 대체 빌드 사양 파일의 경로로 설정합니다. 또한 AWS SDK의 create project 작업과 동등한 작업을 수행할 수 있습니다. 자세한 정보는 빌드 프로젝트 생성 또는 빌드 프로젝트 설정 변경 단원을 참조하십시오.

  • AWS CLI start-build 명령을 실행하여 buildspecOverride 값을 내장 환경 변수 CODEBUILD_SRC_DIR의 값에 상대적인 대체 빌드 사양 파일의 경로로 설정합니다. 또한 AWS SDK의 start build 작업과 동등한 작업을 수행할 수 있습니다. 자세한 정보는 빌드 실행 단원을 참조하십시오.

  • AWS CloudFormation 템플릿에서 AWS::CodeBuild::Project 유형 리소스의 Source에 대한 BuildSpec 속성을 내장 환경 변수 CODEBUILD_SRC_DIR의 값에 상대적인 대체 빌드 사양 파일의 경로로 설정합니다. 자세한 정보는 AWS CloudFormation User GuideAWS CodeBuild 프로젝트 소스에 있는 BuildSpec 속성을 참조하십시오.

빌드 사양 구문

빌드 사양 파일은 YAML 형식을 사용해야 합니다.

중요

Ubuntu 표준 이미지 2.0 이상을 사용하는 경우 buildspec 파일에서 runtime-versions를 지정해야 합니다. 자세한 내용은 Buildspec 파일의 런타임 버전 지정 단원을 참조하십시오.

빌드 사양 구문은 다음과 같습니다.

version: 0.2 run-as: Linux-user-name env: variables: key: "value" key: "value" parameter-store: key: "value" key: "value" git-credential-helper: yes phases: install: run-as: Linux-user-name runtime-versions: runtime: version runtime: version commands: - command - command finally: - command - command pre_build: run-as: Linux-user-name commands: - command - command finally: - command - command build: run-as: Linux-user-name commands: - command - command finally: - command - command post_build: run-as: Linux-user-name commands: - command - command finally: - command - command artifacts: files: - location - location name: artifact-name discard-paths: yes base-directory: location secondary-artifacts: artifactIdentifier: files: - location - location name: secondary-artifact-name discard-paths: yes base-directory: location artifactIdentifier: files: - location - location discard-paths: yes base-directory: location cache: paths: - path - path

빌드 사양에는 다음이 포함되어 있습니다.

  • version: 필수 매핑입니다. 빌드 사양 버전을 나타냅니다. 0.2를 사용할 것을 권장합니다.

    참고

    버전 0.1도 계속 지원되지만 가능하면 버전 0.2를 사용할 것을 권장합니다. 자세한 내용은 빌드 사양 버전를 참조하십시오.

  • run-as: 선택적 시퀀스입니다. Linux 사용자만 사용할 수 있습니다. 이 buildspec 파일의 명령을 실행하는 Linux 사용자를 지정합니다. run-as는 지정한 사용자에게 읽기 및 실행 권한을 부여합니다. buildspec 파일 처음에 run-as를 지정할 경우 모든 명령에 전역적으로 적용됩니다. 모든 buildspec 파일 명령에 대한 사용자를 지정하지 않으려는 경우 phases 블록 중 하나에 run-as를 사용하여 단계에 명령에 대한 사용자를 지정할 수 있습니다. run-as를 지정하지 않으면 모든 명령이 root로 실행됩니다.

  • env: 선택적 시퀀스입니다. 하나 이상의 사용자 지정 환경 변수에 대한 정보를 나타냅니다.

    • variables: env가 지정된 경우 및 사용자 지정 환경 변수를 일반 텍스트로 정의하려고 할 때 필요합니다. key/value 스칼라 매핑을 포함하며, 각 매핑은 일반 텍스트의 단일 사용자 지정 환경 변수를 나타냅니다. key는 사용자 지정 환경 변수의 이름이고, value는 이 변수의 값입니다.

      중요

      중요한 값(특히 AWS 액세스 키 ID 및 보안 액세스 키)을 환경 변수에 저장하지 마십시오. 환경 변수는 CodeBuild 콘솔 및 AWS CLI와 같은 도구를 사용하여 일반 텍스트로 표시할 수 있습니다. 이 단원의 뒷부분에서 설명하는 것처럼 중요한 값의 경우 parameter-store 매핑을 사용하는 것이 좋습니다.

      사용자가 설정한 환경 변수는 기존 환경 변수를 대체합니다. 예를 들어 Docker 이미지에 값이 my_valueMY_VAR이라는 환경 변수가 이미 포함되어 있는데, 사용자가 MY_VAR 환경 변수의 값을 other_value로 설정하면, my_valueother_value로 바뀝니다. 마찬가지로, Docker 이미지에 값이 /usr/local/sbin:/usr/local/binPATH라는 환경 변수가 이미 포함되어 있는데, 사용자가 PATH 환경 변수의 값을 $PATH:/usr/share/ant/bin으로 설정하면, /usr/local/sbin:/usr/local/bin$PATH:/usr/share/ant/bin 리터럴 값으로 바뀝니다.

      CODEBUILD_로 시작하는 이름으로 환경 변수를 설정하지 마십시오. 이 접두사는 내부 전용으로 예약되어 있습니다.

      여러 위치에서 동일한 이름의 환경 변수가 정의되는 경우, 다음과 같이 값이 결정됩니다.

      • 시작 빌드 작업 호출의 값이 가장 높은 우선 순위를 갖습니다. 빌드를 생성할 때 환경 변수를 추가 또는 재정의할 수 있습니다. 자세한 내용은 CodeBuild에서 빌드 실행 단원을 참조하십시오.

      • 빌드 프로젝트 정의의 값이 다음 우선 순위를 갖습니다. 프로젝트를 생성 또는 편집할 때 프로젝트 수준에서 환경 변수를 추가할 수 있습니다. 자세한 내용은 CodeBuild에서 빌드 프로젝트 만들기CodeBuild에서 빌드 프로젝트 설정 변경 섹션을 참조하십시오.

      • 빌드 사양 선언의 값이 가장 낮은 우선 순위를 갖습니다.

    • parameter-store: env가 지정된 경우 및 Amazon EC2 Systems Manager 파라미터 스토어에 저장된 사용자 지정 환경 변수를 검색하려고 할 때 필요합니다. key/value 스칼라 매핑을 포함하며, 각 매핑은 Amazon EC2 Systems Manager Parameter Sotre에 저장된 하나의 사용자 지정 환경 변수를 나타냅니다. key는 이 사용자 지정 환경 변수를 참조하기 위해 나중에 빌드 명령에서 사용할 이름이고, value는 Amazon EC2 Systems Manager 파라미터 스토어에 저장되는 사용자 지정 환경 변수의 이름입니다. 중요한 값을 저장하려면 Amazon EC2 Systems Manager 사용 설명서Systems Manager 파라미터 스토어Systems Manager 파라미터 스토어 콘솔 연습을 참조하십시오.

      중요

      CodeBuild가 Amazon EC2 Systems Manager 파라미터 스토어에 저장된 사용자 지정 환경 변수를 검색하도록 허용하려면 ssm:GetParameters 작업을 CodeBuild 서비스 역할에 추가해야 합니다. 자세한 정보는 CodeBuild 서비스 역할 만들기 단원을 참조하십시오.

      Amazon EC2 Systems Manager 파라미터 스토어에서 검색하는 환경 변수는 기존 환경 변수를 대체합니다. 예를 들어 Docker 이미지에 값이 MY_VARmy_value이라는 환경 변수가 이미 포함되어 있는데, 사용자가 MY_VAR 환경 변수의 값을 other_value로 검색하면, my_valueother_value로 바뀝니다. 마찬가지로, Docker 이미지에 값이 PATH/usr/local/sbin:/usr/local/bin라는 환경 변수가 이미 포함되어 있는데, 사용자가 PATH 환경 변수의 값을 $PATH:/usr/share/ant/bin으로 검색하면, /usr/local/sbin:/usr/local/bin$PATH:/usr/share/ant/bin 리터럴 값으로 바뀝니다.

      CODEBUILD_로 시작하는 이름으로 환경 변수를 저장하지 마십시오. 이 접두사는 내부 전용으로 예약되어 있습니다.

      여러 위치에서 동일한 이름의 환경 변수가 정의되는 경우, 다음과 같이 값이 결정됩니다.

      • 시작 빌드 작업 호출의 값이 가장 높은 우선 순위를 갖습니다. 빌드를 생성할 때 환경 변수를 추가 또는 재정의할 수 있습니다. 자세한 내용은 CodeBuild에서 빌드 실행 단원을 참조하십시오.

      • 빌드 프로젝트 정의의 값이 다음 우선 순위를 갖습니다. 프로젝트를 생성 또는 편집할 때 프로젝트 수준에서 환경 변수를 추가할 수 있습니다. 자세한 내용은 CodeBuild에서 빌드 프로젝트 만들기CodeBuild에서 빌드 프로젝트 설정 변경 섹션을 참조하십시오.

      • 빌드 사양 선언의 값이 가장 낮은 우선 순위를 갖습니다.

    • git-credential-helper: 선택적 매핑입니다. CodeBuild가 Git 자격 증명 헬퍼를 사용하여 Git 자격 증명을 제공하는지를 나타냅니다. Git 자격 증명 헬퍼가 사용되는 경우 yes이고, 그렇지 않은 경우 no이거나 값이 지정되지 않은 것입니다. 자세한 내용은 Git 웹사이트의 gitcredentials를 참조하십시오.

  • phases: 필수 시퀀스입니다. 빌드의 각 단계 동안 CodeBuild가 실행하는 명령을 나타냅니다.

    참고

    빌드 사양 버전 0.1에서 CodeBuild는 빌드 환경에 있는 기본 셸의 서로 다른 인스턴스에서 각 명령을 실행합니다. 즉, 각 명령이 다른 모든 명령과 독립적으로 실행됩니다. 따라서 기본적으로 이전 명령의 상태에 따라 실행되는 단일 명령을 실행할 수 없습니다(예: 디렉터리 변경 또는 환경 변수 설정). 이 제한 사항을 해결하려면 이 문제를 해결하는 버전 0.2를 사용하는 것이 좋습니다. 빌드 사양 버전 0.1을 사용해야 하는 경우 빌드 환경의 셸 및 명령에 나온 접근 방식을 따르는 것이 좋습니다.

    • run-as: 선택적 시퀀스입니다. 해당 명령을 실행하는 Linux 사용자를 지정하려면 빌드 단계에 사용합니다. buildspec 파일의 상단에 모든 명령에 대해 전역적으로 run-as도 지정할 경우 단계 수준 사용자가 우선 적용됩니다. 예를 들어 run-as가 전역적으로 User-1을 지정하고 install 단계에만 run-as 문이 User-2를 지정할 경우, buildspec 파일의 모든 명령이 User-1로 실행되지만 install 단계의 명령은 User-2로 실행됩니다.

    허용되는 빌드 단계 이름은 다음과 같습니다.

    • install: 선택적 시퀀스입니다. 설치 중에 CodeBuild가 실행하는 명령을 나타냅니다(있는 경우). 빌드 환경에서 패키지를 설치하는 경우에만 install 단계를 사용하는 것이 좋습니다. 예를 들어, Mocha나 RSpec 같은 코드 테스팅 프레임워크를 설치하기 위해 이 단계를 사용할 수 있습니다.

      • runtime-versions: Ubuntu 표준 이미지 2.0을 사용하는 경우 필요합니다. 사용자 지정 이미지 또는 Ubuntu 표준 이미지 1.0에는 런타임 버전이 지원되지 않습니다. 지정된 경우 적어도 하나의 실행 시간이 이 섹션에 포함되어야 합니다. "java: openjdk11" 또는 "ruby: 2.6"과 같은 메이저 버전만 사용하여 실행 시간을 지정하십시오. 숫자나 환경 변수를 사용하여 실행 시간을 지정할 수 있습니다. 예를 들어 다음은 openjdk 버전 8, android 버전 28 및 ruby의 환경 변수에 포함된 버전이 설치되도록 지정합니다. 자세한 내용은 CodeBuild가 제공하는 Docker 이미지 단원을 참조하십시오.

        참고

        runtime-versions 섹션을 지정하고 Ubuntu Standard Image 2.0 이상이 아닌 이미지를 사용하면 빌드에서 "런타임 설치를 건너뜁니다. 이 빌드 이미지에서는 런타임 버전 선택이 지원되지 않습니다." 경고가 발생합니다.

        phases: install: runtime-versions: java: openjdk8 android: 28 ruby: "$MY_RUBY_VAR"
        • 일부 실행 시간은 특정 버전의 다른 실행 시간을 포함해야 합니다. 필수 실행 시간이 지정되지 않으면 빌드가 실패합니다. 예를 들어 android 버전 28에는 openjdk 버전 8이 필요합니다. android: 28이 지정되고 openjdk: 8이 지정되지 않은 경우 빌드가 실패합니다.

        • 지정된 두 실행 시간이 충돌하면 빌드가 실패합니다. 예를 들어 android: 8java: openjdk11이 충돌하고 둘 다 지정되면 빌드가 실패합니다.

        • 다음 실행 시간을 지정할 수 있습니다.

          실행 시간 이름 버전 buildspec 파일에서 지정하는 방법
          android 28 android: 28
          docker 18 docker: 18
          dotnet 2.2 dotnet: 2.2
          golang 1.12 golang: 1.12
          nodejs 8, 10 nodejs: 8, nodejs: 10
          java openjdk8, openjdk11 java: openjdk8, java: openjdk11
          php 7.3 php: 7.3
          python 3.7 python: 3.7
          ruby 2.6 ruby: 2.6
      • commands: runtime-versions를 지정하지 않을 경우 필수 시퀀스입니다. runtime-versions를 지정할 경우 선택 사항입니다. 스칼라 시퀀스를 포함하며, 각 스칼라는 설치 중에 CodeBuild가 실행하는 단일 명령을 나타냅니다. CodeBuild는 처음부터 끝까지 한 번에 하나씩 나열된 순서로 각 명령을 실행합니다.

    • pre_build: 선택적 시퀀스입니다. 빌드 전에 CodeBuild가 실행하는 명령을 나타냅니다(있는 경우). 예를 들어, Amazon ECR에 로그인하기 위해 이 단계를 사용할 수 있습니다. 또는 npm 종속성을 설치할 수도 있습니다.

      • commands: pre_build을 지정한 경우 필수 시퀀스입니다. 스칼라 시퀀스를 포함하며, 각 스칼라는 빌드 전에 CodeBuild가 실행하는 단일 명령을 나타냅니다. CodeBuild는 처음부터 끝까지 한 번에 하나씩 나열된 순서로 각 명령을 실행합니다.

    • build: 선택적 시퀀스입니다. 빌드 중에 CodeBuild가 실행하는 명령을 나타냅니다(있는 경우). 예를 들어, Mocha, RSpec 또는 sbt를 실행하기 위해 이 단계를 사용할 수 있습니다.

      • commands: build를 지정한 경우 필수입니다. 스칼라 시퀀스를 포함하며, 각 스칼라는 빌드 중에 CodeBuild가 실행하는 단일 명령을 나타냅니다. CodeBuild는 처음부터 끝까지 한 번에 하나씩 나열된 순서로 각 명령을 실행합니다.

    • post_build: 선택적 시퀀스입니다. 빌드 후에 CodeBuild가 실행하는 명령을 나타냅니다(있는 경우). 예를 들어, Maven을 사용하여 빌드 결과물을 JAR 또는 WAR 파일에 패키지할 수 있으며, Amazon ECR에 Docker 이미지를 푸시할 수도 있습니다. 그런 다음 Amazon SNS를 통해 빌드 알림을 전송할 수도 있습니다.

      • commands: post_build를 지정한 경우 필수입니다. 스칼라 시퀀스를 포함하며, 각 스칼라는 빌드 후에 CodeBuild가 실행하는 단일 명령을 나타냅니다. CodeBuild는 처음부터 끝까지 한 번에 하나씩 나열된 순서로 각 명령을 실행합니다.

    중요

    일부 빌드 단계의 명령은 앞의 빌드 단계 명령이 실패하는 경우 실행되지 않을 수 있습니다. 예를 들어 install 단계 중에 명령이 실패하는 경우 pre_build, buildpost_build 단계의 명령은 모두 해당 빌드의 수명 주기 동안에는 실행되지 않습니다. 자세한 정보는 빌드 단계 진행 단원을 참조하십시오.

  • finally: 선택적 블록입니다. finally 블록에 지정된 명령은 commands 블록의 명령 후에 실행됩니다. finally 블록의 명령은 commands 블록의 명령이 실패할 경우에도 실행됩니다. 예를 들어 명령 3개가 포함된 commands 블록에서 첫 번째 명령이 실패할 경우, CodeBuild는 나머지 두 명령을 건너뛰고 finally 블록의 명령을 실행합니다. commandsfinally 블록의 모든 명령이 성공적으로 실행되면 단계가 성공합니다. 어느 단계의 명령이 하나라도 실패하면 그 단계는 실패합니다.

  • artifacts: 선택적 시퀀스입니다. CodeBuild가 빌드 출력을 찾을 수 있는 위치 및 CodeBuild가 Amazon S3 출력 버킷에 업로드하기 위해 빌드 출력을 준비하는 방식에 대한 정보를 나타냅니다. Docker 이미지를 빌드하여 Amazon ECR에 푸시하는 경우 또는 소스 코드에 단위 테스트만 실행하고 빌드는 하지 않는 경우 등에는 이 시퀀스가 필요하지 않습니다.

    • files: 필수 시퀀스입니다. 빌드 환경의 빌드 출력 결과물을 포함하는 위치를 나타냅니다. 스칼라 시퀀스를 포함하며, 각 스칼라는 CodeBuild가 빌드 출력 결과물을 찾을 수 있는 개별 위치를 원래 빌드 위치 또는 기본 디렉터리(설정한 경우)를 기준으로 나타냅니다. 위치에는 다음이 포함될 수 있습니다.

      • 단일 파일(예: my-file.jar).

      • 하위 디렉터리의 단일 파일입니다(예: my-subdirectory/my-file.jar 또는 my-parent-subdirectory/my-subdirectory/my-file.jar).

      • '**/*'는 모든 파일을 재귀적으로 나타냅니다.

      • my-subdirectory/*my-subdirectory라는 하위 디렉터리에 있는 모든 파일을 나타냅니다.

      • my-subdirectory/**/*my-subdirectory라는 하위 디렉터리에서 시작하는 모든 파일을 재귀적으로 나타냅니다.

      빌드 출력 결과물 위치를 지정하면 CodeBuild가 빌드 환경의 원래 빌드 위치를 찾을 수 있습니다. 빌드 결과물 출력 위치 앞에 원래 빌드 위치 경로를 추가하거나 ./ 같은 것을 지정하지 않아도 됩니다. 이 위치에 대한 경로를 알고 싶으면 빌드 중에 echo $CODEBUILD_SRC_DIR과 같은 명령을 실행하면 됩니다. 각 빌드 환경의 위치는 약간씩 다를 수 있습니다.

    • name: 선택적 이름입니다. 빌드 결과물의 이름을 지정합니다. 이 이름은 다음 중 하나에 해당될 때 사용됩니다.

      • CodeBuild API를 사용하여 빌드를 생성하면 프로젝트가 업데이트되거나 생성되거나 빌드가 시작될 때 ProjectArtifacts 객체에 overrideArtifactName 플래그가 설정됩니다.

      • CodeBuild 콘솔을 사용하여 빌드를 생성하면 buildspec 파일에 이름이 지정되고, 프로젝트를 만들거나 업데이트할 때 buildspec 파일에 지정된 이름 사용을 선택합니다. 자세한 정보는 빌드 프로젝트 만들기(콘솔) 단원을 참조하십시오.

      빌드 시 계산되는 빌드 사양 파일에 이름을 지정할 수 있습니다. 빌드 사양 파일에 지정된 이름은 Shell 명령 언어를 사용합니다. 예를 들어 결과물 이름이 항상 고유하도록 날짜와 시간을 결과물 이름에 추가할 수 있습니다. 고유한 결과물 이름을 사용하면 결과물을 덮어쓰지 않을 수 있습니다. 자세한 정보는 Shell 명령 언어를 참조하십시오.

      다음은 결과물이 생성된 날짜가 추가된 결과물 이름의 예입니다

      version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: myname-$(date +%Y-%m-%d)

      다음은 CodeBuild 환경 변수를 사용하는 결과물 이름의 예입니다. 자세한 내용은 빌드 환경의 환경 변수 단원을 참조하십시오.

      version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: myname-$(AWS_REGION)

      다음은 CodeBuild 환경 변수를 사용하여 결과물 생성 날짜가 추가된 결과물 이름의 예입니다.

      version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: $(AWS_REGION)-$(date +%Y-%m-%d)
    • discard-paths: 선택적 매핑입니다. 빌드 출력 결과물의 파일 경로가 삭제되는지 여부를 나타냅니다. 경로가 삭제되는 경우 yes이고, 그렇지 않은 경우 no이거나 값이 지정되지 않은 것입니다(기본값). 예를 들어, 빌드 출력 결과물의 파일 경로가 com/mycompany/app/HelloWorld.java인 경우 yes를 지정하면 이 경로가 HelloWorld.java로 간단하게 줄어듭니다.

    • base-directory: 선택적 매핑입니다. CodeBuild가 빌드 출력 결과물에 포함할 파일 및 하위 디렉터리를 결정하는 데 사용하는 원래 빌드 위치에 상대적인 하나 이상의 최상위 디렉터리를 나타냅니다. 유효한 값으로는 다음이 포함됩니다.

      • 단일 최상위 디렉터리입니다(예: my-directory).

      • 'my-directory*'는 이름이 my-directory로 시작하는 모든 최상위 디렉터리를 나타냅니다.

      빌드 출력 결과물에는 이 최상위 디렉터리가 포함되지 않으며, 파일 및 하위 디렉터리만 포함됩니다.

      포함할 파일 및 하위 디렉터리를 보다 더 제한하려면 filesdiscard-paths를 사용하면 됩니다. 예를 들어 다음 디렉터리구조에서

      |-- my-build1 | `-- my-file1.txt `-- my-build2 |-- my-file2.txt `-- my-subdirectory `-- my-file3.txt

      다음 artifacts 시퀀스에 대해:

      artifacts: files: - '*/my-file3.txt' base-directory: my-build2

      다음 하위 디렉터리 및 파일이 빌드 출력 결과물에 포함됩니다.

      my-subdirectory `-- my-file3.txt

      다음 artifacts 시퀀스 동안

      artifacts: files: - '**/*' base-directory: 'my-build*' discard-paths: yes

      다음 파일이 빌드 출력 결과물에 포함됩니다.

      |-- my-file1.txt |-- my-file2.txt `-- my-file3.txt
    • secondary-artifacts: 선택적 시퀀스입니다. 1개 이상의 아티팩트 정의를 아티팩트 식별자와 아티팩트 정의를 연결하는 매핑으로 나타냅니다. 이 블록에서는 각 아티팩트가 프로젝트의 secondaryArtifacts 속성에서 정의하는 아티팩트와 일치해야 합니다. 각 정의는 위의 artifacts: 블록과 동일한 구문을 갖습니다. 예를 들어 프로젝트가 다음과 같은 구조라고 가정할 경우,

      { "name": "sample-project", "secondaryArtifacts": [ { "type": "S3", "location": "output-bucket1", "artifactIdentifier": "artifact1", "name": "secondary-artifact-name-1" }, { "type": "S3", "location": "output-bucket2", "artifactIdentifier": "artifact2", "name": "secondary-artifact-name-2" } ] }

      buildpec 파일은 다음과 비슷합니다.

      version: 0.2 phases: build: commands: - echo Building... artifacts: secondary-artifacts: artifact1: files: - directory/file name: secondary-artifact-name-1 artifact2: files: - directory/file2 name: secondary-artifact-name-2
  • cache: 선택적 시퀀스입니다. CodeBuild가 Amazon S3 캐시 버킷에 캐시를 업로드하기 위해 준비할 수 있는 파일에 대한 정보를 나타냅니다. 프로젝트의 캐시 유형이 No Cache인 경우 이 시퀀스는 필수가 아닙니다.

    • paths: 필수 시퀀스입니다. 캐시의 위치를 나타냅니다. 스칼라 시퀀스를 포함하며, 각 스칼라는 CodeBuild가 빌드 출력 결과물을 찾을 수 있는 개별 위치를 원래 빌드 위치 또는 기본 디렉터리(설정한 경우)를 기준으로 나타냅니다. 위치에는 다음이 포함될 수 있습니다.

      • 단일 파일(예: my-file.jar).

      • 하위 디렉터리의 단일 파일입니다(예: my-subdirectory/my-file.jar 또는 my-parent-subdirectory/my-subdirectory/my-file.jar).

      • '**/*'는 모든 파일을 재귀적으로 나타냅니다.

      • my-subdirectory/*my-subdirectory라는 하위 디렉터리에 있는 모든 파일을 나타냅니다.

      • my-subdirectory/**/*my-subdirectory라는 하위 디렉터리에서 시작하는 모든 파일을 재귀적으로 나타냅니다.

중요

빌드 사양 선언은 올바른 YAML이어야 하므로 빌드 사양 선언의 공백이 중요합니다. 빌드 사양 선언의 공백 수가 맞지 않으면 빌드가 즉시 실패할 수 있습니다. YAML 검사기를 사용하여 빌드 사양 선언이 올바른 YAML인지 여부를 테스트할 수 있습니다.

빌드 프로젝트를 생성하거나 업데이트할 때 AWS CLI 또는 AWS SDK를 사용하여 빌드 사양을 선언하는 경우, 빌드 사양이 YAML 형식으로 표현된 단일 문자열이어야 하며, 공백 및 줄바꿈 이스케이프 문자가 꼭 있어야 합니다. 다음 섹션에 예가 나와 있습니다.

buildspec.yml 파일 대신 CodeBuild 또는 AWS CodePipeline 콘솔을 사용하는 경우 build 단계의 명령만 삽입할 수 있습니다. 앞에 나온 구문을 사용하는 대신, 빌드 단계 중에 실행하려는 모든 명령을 하나의 행에 나열합니다. 명령이 여러 개인 경우 각 명령을 &&로 구분합니다(예: mvn test && mvn package).

buildspec.yml 파일 대신 CodeBuild 또는 CodePipeline 콘솔을 사용하여 빌드 환경의 빌드 출력 결과물 위치를 지정할 수 있습니다. 앞에 나온 구문을 사용하는 대신, 모든 위치를 하나의 행에 나열합니다. 위치가 여러 개인 경우 각 위치를 쉼표로 구분합니다(예: buildspec.yml, target/my-app.jar).

빌드 사양 예

다음은 buildspec.yml 파일의 예입니다.

version: 0.2 env: variables: JAVA_HOME: "/usr/lib/jvm/java-8-openjdk-amd64" parameter-store: LOGIN_PASSWORD: /CodeBuild/dockerLoginPassword phases: install: commands: - echo Entered the install phase... - apt-get update -y - apt-get install -y maven finally: - echo This always runs even if the update or install command fails pre_build: commands: - echo Entered the pre_build phase... - docker login –u User –p $LOGIN_PASSWORD finally: - echo This always runs even if the login command fails build: commands: - echo Entered the build phase... - echo Build started on `date` - mvn install finally: - echo This always runs even if the install command fails post_build: commands: - echo Entered the post_build phase... - echo Build completed on `date` artifacts: files: - target/messageUtil-1.0.jar discard-paths: yes secondary-artifacts: artifact1: files: - target/messageUtil-1.0.jar discard-paths: yes artifact2: files: - target/messageUtil-1.0.jar discard-paths: yes cache: paths: - '/root/.m2/**/*'

다음은 앞에 나온 빌드 사양의 예로, AWS CLI 또는 AWS SDK와 함께 사용하기 위해 단일 문자열로 표현한 것입니다.

"version: 0.2\n\nenv:\n variables:\n JAVA_HOME: "/usr/lib/jvm/java-8-openjdk-amd64"\n parameter-store:\n LOGIN_PASSWORD: /CodeBuild/dockerLoginPassword\n\nphases:\n install:\n commands:\n - apt-get update -y\n - apt-get install -y maven\n pre_build:\n commands:\n - echo Entered the pre_build phase...\n build:\n commands:\n - echo Build started on `date`\n - mvn install\n post_build:\n commands:\n - echo Build completed on `date`\nartifacts:\n files:\n - target/messageUtil-1.0.jar\n discard-paths: yes"

다음은 CodeBuild 또는 CodePipeline 콘솔과 함께 사용하기 위한 build 단계의 명령 예입니다.

echo Build started on `date` && mvn install

아래 예에서

  • JAVA_HOME의 키 및 /usr/lib/jvm/java-8-openjdk-amd64의 값이 있는 일반 텍스트의 사용자 지정 환경 변수가 설정됩니다.

  • Amazon EC2 Systems Manager 파라미터 스토어에 저장된 dockerLoginPassword라는 사용자 지정 환경 변수는 나중에 LOGIN_PASSWORD 키를 사용하여 빌드 명령에서 참조됩니다.

  • 이러한 빌드 단계 이름은 변경할 수 없습니다. 이 예에서 실행될 명령은 apt-get update -yapt-get install -y maven(Apache Maven을 설치하는 데 사용), mvn install(소스 코드를 빌드 출력 결과물로 컴파일, 테스트 및 패키징하고 빌드 출력 결과물을 내부 리포지토리에 설치하는 데 사용), docker login(Amazon EC2 Systems Manager Parameter Store에 설정한 사용자 지정 환경 변수 dockerLoginPassword의 값에 해당하는 암호로 Docker에 로그인하는 데 사용) 및 여러 echo 명령입니다. echo 명령은 CodeBuild가 명령을 실행하는 방식 및 명령 실행 순서를 보여 주기 위해 포함된 것입니다.

  • files는 빌드 출력 위치에 업로드할 파일을 나타냅니다. 이 예에서 CodeBuild는 이라는 단일 messageUtil-1.0.jar 파일을 업로드합니다. messageUtil-1.0.jar 파일은 빌드 환경의 target이라는 상대적 디렉터리에서 찾을 수 있습니다. discard-paths: yes가 지정되어 있으므로, messageUtil-1.0.jar가 바로 업로드됩니다(중간의 target 디렉터리를 거치지 않음). 파일 이름 messageUtil-1.0.jar 및 상대적 디렉터리 이름 target은 Apache Maven이 이 예제에서만 빌드 출력 결과물을 생성 및 저장하는 방식에 따라 달라집니다. 사용자 자체 시나리오에서는 이러한 파일 이름과 디렉터리가 다릅니다.

빌드 사양 버전

다음 표에는 빌드 사양 버전과 버전 간 변경 사항이 나열되어 있습니다.

버전 변경
0.2
  • environment_variables의 이름이 env로 다시 지정되었습니다.

  • plaintext의 이름이 variables로 다시 지정되었습니다.

  • 버전 0.1에서 AWS CodeBuild는 빌드 환경에 있는 기본 셸의 서로 다른 인스턴스에서 각 빌드 명령을 실행합니다. 버전 0.2에서 CodeBuild는 빌드 환경에 있는 기본 셸의 동일한 인스턴스에서 모든 빌드 명령을 실행합니다.

0.1 이는 빌드 사양 형식의 초기 정의입니다.