This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.

Status	Authors	Coach	DRIs	Owning Stage	Created
proposed				devops verify	-

디자인 및 구현 세부 정보

기준 스텝 프로토

Step Runner 내부 동작은 프로토콜 버퍼에 정의된 기준 스텝 정의를 기반으로 합니다. 모든 GitLab CI 스텝(및 GitHub Actions과 같은 다른 지원되는 형식)은 기준 스텝으로 컴파일/폴딩됩니다. .gitlab-ci.yml에서 스텝 호출 및 step.yml 파일에서의 스텝 정의는 모두 기준 구조로 컴파일됩니다. 이 문서에서는 “스텝(step)”이라는 용어는 “기준 스텝”을 의미합니다.

각 스텝에는 URI 형식의 참조 ref가 포함됩니다. URI의 프로토콜에 따라 검색 방법이 결정됩니다.

스텝 및 스텝 트레이스에는 입력, 출력, 환경 변수 및 환경 내보내기 필드가 포함됩니다. 스텝이 다운로드되고 step.yml이 구문 분석된 후에는 스텝 정의 def가 추가됩니다. 스텝이 여러 추가 스텝을 정의하는 경우 트레이스에는 각 하위 스텝에 대한 하위 트레이스가 포함됩니다.

message Step {
    string name = 1;
    string step = 2;
    map<string,string> env = 3;
    map<string,google.protobuf.Value> inputs = 4;
}

message Definition {
    DefinitionType type = 1;
    Exec exec = 2;
    repeated Step steps = 3;
    message Exec {
        repeated string command = 1;
        string work_dir = 2;
    }
}

enum DefinitionType {
    definition_type_unspecified = 0;
    exec = 1;
    steps = 2;
}

message Spec {
    Content spec = 1;
    message Content {
        map<string,Input> inputs = 1;
        message Input {
            InputType type = 1;
            google.protobuf.Value default = 2;
        }
    }
}

enum InputType {
    spec_type_unspecified = 0;
    string = 1;
    number = 2;
    bool = 3;
    struct = 4;
    list = 5;
}

message StepResult {
    Step step = 1;
    Spec spec = 2;
    Definition def = 3;
    enum Status {
        unspecified = 0;
        running = 1;
        success = 2;
        failure = 3;
    }
    Status status = 4;
    map<string,Output> outputs = 5;
    message Output {
        string key = 1;
        string value = 2;
        bool masked = 3;
    }
    map<string,string> exports = 6;
    int32 exit_code = 7;
    repeated StepResult children_step_results = 8;
}

스텝 캐싱

스텝은 location (URL), version, hash로 구성된 키에 의해 로컬로 캐시됩니다. 이를 통해 정확히 동일한 컴포넌트가 여러 번 다운로드되는 것을 방지합니다. 처음으로 스텝을 참조할 때는 다운로드됩니다(로컬이 아닌 경우) 및 캐시는 step.yml 및 다른 스텝 파일이 포함된 폴더의 경로를 반환합니다. 동일한 스텝을 다시 참조하는 경우 동일한 폴더가 다운로드 없이 반환됩니다.

다른 캐시된 스텝에서 버전 또는 해시에 따라 다른 참조 스텝이 참조되면 다른 폴더로 다시 다운로드되어 별도로 캐시됩니다.

실행 컨텍스트

스텝 러너는 실행 컨텍스트 형식으로 모든 스텝의 상태를 유지합니다. 컨텍스트에는 각 스텝의 출력, 환경 변수 및 전반적인 작업 및 환경 메타데이터가 포함됩니다. 작업 흐름 작성자가 제공하는 GitLab CI 스텝에서 표현식으로 컨텍스트를 참조할 수 있습니다.

.gitlab-ci.yml에서 표현식에 사용 가능한 컨텍스트의 예시:

steps:
  previous_step:
    outputs:
      name: "hello world"
env:
  EXAMPLE_VAR: "bar"
job:
  id: 1234

스텝 정의의 표현식도 실행 컨텍스트를 참조할 수 있습니다. 그러나 이들은 전반적인 작업과 환경 메타데이터 및 step.yml에서 정의된 입력에만 액세스할 수 있습니다. 이들은 이전 스텝의 출력에 액세스할 수 없습니다. 다음에 출력을 제공하기 위해 스텝 입력 값에는 다른 스텝의 출력을 참조하는 표현식이 포함되어야 합니다.

step.yml에서 표현식에 사용 가능한 컨텍스트의 예시:

inputs:
  name: "foo"
env:
  EXAMPLE_VAR: "bar"
job:
  id: 1234

예를 들어, 스텝은 서로 결합해서는 안 되기 때문에 step.yml 파일에서는 다음과 같은 작업이 허용되지 않습니다.

spec:
  inputs:
    name:
---
type: exec
exec:
  command: [echo, hello, ${{ steps.previous_step.outputs.name }}]

GitLab CI 스텝 구문은 한 스텝에서 다른 스텝으로 데이터를 전달하므로 다음과 같은 작업이 허용됩니다.

spec:
  inputs:
    name:
---
type: exec
exec:
  command: [echo, hello, ${{ inputs.name }}]

steps:
- name: previous_step
  ... 
- name: greeting
  inputs:
    name: ${{ steps.previous_step.outputs.name }}

따라서 표현식의 평가는 GitLab CI 스텝 형식과 스텝 정의로 두 가지 다른 종류의 컨텍스트에서 이루어집니다.

스텝 입력

스텝 입력은 여러 가지 방식으로 제공될 수 있습니다. exec 명령어의 표현식에 직접 임베드될 수 있습니다(위 참조). 또는 실행 중에 설정된 환경 변수에 대한 표현식에 임베드될 수 있습니다.

spec:
  inputs:
    name:
---
type: exec
exec:
  command: [greeting.sh]
env:
  NAME: ${{ inputs.name }}

입력 유형

입력 값은 문자열로 저장됩니다. 그러나 이들은 함께 연관된 유형을 가질 수 있습니다. 지원되는 유형은 다음과 같습니다.

string
bool
number
object

문자열 유형 값은 모든 문자열이 될 수 있습니다. Bool 유형 값은 JSON으로 구문 분석될 때 true 또는 false이어야 합니다. 숫자 유형 값은 JSON으로 구문 분석될 때 유효한 float64여야 합니다. 객체 유형 값은 YAML 입력 구조의 JSON 직렬화가 될 것입니다.

예를 들어, 다음은 유효한 입력입니다.

steps:
- name: my_step
  inputs:
    foo: bar
    baz: true
    bam: 1

다음 스텝 정의를 고려하면:

spec:
  inputs:
    foo:
      type: string
    baz:
      type: bool
    bam:
      type: number
---
type: exec
exec:
  command: [echo, ${{ inputs.foo }}, ${{ inputs.baz }}, ${{ inputs.bam }}]

그리고 이는 bar true 1을 출력할 것입니다.

객체 유형의 경우, 다음은 유효한 입력입니다:

steps:
  name: my_step
  inputs:
    foo:
      steps:
      - name: my_inner_step
        inputs:
          name: steppy

다음 스텝 정의를 고려하면:

spec:
  inputs:
    foo:
      type: object
---
type: exec
exec:
  command: [echo, ${{ inputs.foo }}]

그리고 이는 {"steps":[{"name":"my_inner_step","inputs":{"name":"steppy"}}]}을 출력할 것입니다.

위임 (선택한 옵션)

단계에 복잡한 구조를 전달할 수 있도록 하는 규정이 마련되었으며, 이는 그것들을 JSON으로 직렬화하는 것입니다 (위의 입력 사항 참조). 이렇게 하면 컨테이너에서 실행될 실제 단계가 바깥의 단계에서 매개변수로만 전달될 수 있습니다. 따라서 바깥 단계는 docker/run 단계로, step-runner를 steps 입력 매개변수와 함께 실행하는 명령이 포함된 것입니다. docker/run 단계는 컨테이너를 실행한 다음 출력 파일을 컨테이너에서 추출하여 이를 바깥 단계에 다시 전달합니다.

이 기술은 VM에서 또는 기타 환경에서 단계를 실행하는 데에도 동작합니다. Step Runner는 단계를 컨테이너화하거나 격리하는 데 대해 알 필요가 없습니다.

특별한 컴파일 (거부된 옵션)

GitLab CI 단계에서 image 키워드를 볼 때, “대상” 단계를 다운로드하고 컴파일할 것입니다. 그런 다음 docker/run 단계를 생성하고 컴파일된 exec 명령을 입력으로 전달할 것입니다. 그런 다음 docker/run 단계를 컴파일하고 실행할 것입니다.

그러나 이것은 Step Runner가 docker/run 단계를 어떻게 구성할 지를 알아야 한다는 것을 요구합니다. 이는 Step Runner를 격리 방법에 결합시켜 VM 및 기타 방법의 격리를 더 복잡하게 만듭니다.

내부 도커 (거부된 옵션)

기본 단계는 도커 컨테이너에서 단계를 실행할 수 있는 규정을 포함할 수 있습니다. 예를 들어, 단계에는 ref “대상” 필드와 image 필드가 포함될 수 있습니다.

그러나 이는 Step Runner를 도커와 결합시키고 Step Runner의 역할을 확장시키게 됩니다. 도커를 Step Runner가 아닌 단순히 다른 단계처럼 외부 단계로 만드는 것이 바람직합니다.