Github Repo Link

Github 작업의 런타임 변수

객관적

Github Actions는 CI/CD 파이프라인을 작성하고 실행하는 데 유행하는 선택이지만, 특히 Github에 위탁 관리되는 개원 프로젝트에 대해서는 다른 CI/CD 환경에서의 특정한 삶의 질 특성이 부족하다.Github 작업이 아직 실현되지 않은 관건적인 특성 중 하나는 실행 시 변수를 모의하여 작업 흐름에 주입하여 파이프 자체를 테스트할 수 있도록 하는 것이다.
이것은 Azure 개발자 작업에서 미리 존재하는 기능과 Github 작업에서 아직 발표되지 않은 기능 사이에 다리를 제공한다.

대상 시청자

이 설명서는 CI/CD에 익숙하고 CI/CD 파이프의 보안 의미를 이해한다고 가정합니다.또한 기본적인 CI/CD 파이프라인을 작성하고 실행하는 방법, 작업에서 저장소를 체크 아웃하는 방법, 버전 제어가 있는 Marketplace 작업 등을 포함한 Github 작업의 기본 지식을 가정했습니다.
우리는 CI/CD 엔지니어로서 환경 변수나 환경 표지를 파이프와 작업 흐름에 주입하여 테스트하고 Github 조작을 사용하여 이를 실현하고자 한다고 가정합니다.

장면 사용

많은 집적 또는 종합적인 작업 흐름은 특정한 환경 변수를 필요로 하는데, 이러한 변수는rutime에서만 사용할 수 있다.예를 들어, 워크플로우가 다음 작업을 수행하고 있을 수 있습니다.

이런 상황에서 자원에 대한 외부 호출이 필요 없는 상황에서 파이프를 테스트하는 것은 매우 어렵다.많은 상황에서 자원에 대한 외부 호출은 매우 비싸거나 시간이 소모되어 내부 순환의 개발을 크게 늦출 수 있다.
예를 들어, Azure Dev Ops는 수동 트리거에서 파이프 변수를 정의하는 방법을 제공합니다.

Github 작업은 아직 이러한 작업을 수행하지 못했습니다.

솔루션

이 문제를 해결하기 위해 가장 간단한 해결 방안은 실행 시 변수를 제출 메시지나 PR 본문에 추가하고 변수를 추가하는 것이다grep.Github Actions는 grep 함수를 사용하여 이 함수를 독점적으로 사용합니다.

범위 내

우리는 그것의 범위를 이전에 알고 있던 키와 값을 사용하여 하나의 환경 변수를 파이프에 주입할 때까지 확장할 것이다.

범위를 벗어나다

이 해결 방안은 셸 스크립트나 다른 변수를 만드는 방법으로 확장할 수 있지만 이 해결 방안은 기본 개념을 잘 증명했다.이 안내서에는 이러한 스크립트가 제공되지 않습니다.

또한 팀은 PR 템플릿을 사용하여 이 과정을 형식화하기를 원할 수 있습니다. 이 템플릿은 제공하는 변수에 추가 부분이 있습니다.단, 이 안내서에는 이 점이 포함되지 않습니다.

보안 경고

이것은 비밀을 주입하기 위해서가 아니다. 제출 메시지와 PR 본문은 제3자가 검색하여 contains에 저장할 수 있고 악의적인 개인이 각종 도구를 사용하여 읽을 수 있기 때문이다.반대로 간단 변수를 주입해야 하는 작업 흐름을 테스트하기 위한 것이다.
기밀이나 민감한 정보를 검색하려면 Github Action for Azure Key Vault 또는 기타 유사한 기밀 저장 및 검색 서비스를 사용하십시오.

메시지 변수 제출

지정한 키와 값을 사용하여 하나의 변수를 환경에 주입하여 사용할 수 있도록 하는 방법이 예에서 키는 git log, 값은 COMMIT_VAR 입니다.

예비 지식

파이프 트리거가 전송 제출 시 트리거로 올바르게 설정됨 [commit var]

코드 세그먼트

on:
  push:
    branches:
      - actions-test-branch

jobs:
  Echo-On-Commit:
    runs-on: ubuntu-latest
    steps:
      - name: "Checkout Repository"
        uses: actions/checkout@v2

      - name: "Set flag from Commit"
        env:
          COMMIT_VAR: ${{ contains(github.event.head_commit.message, '[commit var]') }}
        run: |
          if ${COMMIT_VAR} == true; then
            echo "::set-env name=flag::true"
            echo "flag set to true"
          else
            echo "::set-env name=flag::false"
            echo "flag set to false"
          fi

      - name: "Use flag if true"
        if: env.flag
        run: echo "Flag is available and true"

할 수 있다.YAMLhere.

코드 해석

코드의 첫 번째 부분은 작업 지점에 푸시 트리거를 설정하고 저장소를 서명하는 것이기 때문에 우리는 상세한 연구를 하지 않을 것이다.

  - name: "Set flag from Commit"
    env:
      COMMIT_VAR: ${{ contains(github.event.head_commit.message, '[commit var]') }}

이것은 Github 작업 파이핑에서 고유한 작업의 명명된 단계입니다.여기서 우리는 단계를 위해 환경 변수를 설정했다. 단계에서 호출된 모든 코드나 조작은 현재 사용할 수 있는 환경 변수를 가지고 있을 것이다.actions-test-branch는 기본적으로 모든 워크플로우에서 사용할 수 있는 Github 작업 기능입니다.부울 값 contains 또는 true 을 반환합니다.이 경우 마지막 푸시 시 제출 메시지 false 를 사용했는지 확인합니다.github.event.head_commit.message 는 Github 컨텍스트를 사용하고 함수 및 ${{...}} 변수를 명령에 사용할 수 있도록 합니다.

  run: |
    if ${COMMIT_VAR} == true; then
      echo "::set-env name=flag::true"
      echo "flag set to true"
    else
      echo "::set-env name=flag::false"
      echo "flag set to false"
    fi

여기에서 github.event 명령 검사run 변수가 COMMIT_VAR 로 설정되었는지 확인하고, 설정된 경우 보조 로고를true로 설정하고 이 동작에 응답합니다.변수가 true 이면 동일한 작업을 수행합니다.
이렇게 하는 구체적인 원인은 진일보한 단계에서 false 변수를 사용할 수 있고 각 단계에서 다시 사용할 필요가 없기 때문이다flag.또한 코드 세그먼트의 다음 부분과 같이 조작된 COMMIT_VAR 단계에서 로고를 사용할 수 있습니다.

- name: "Use flag if true"
  if: env.flag
  run: echo "Flag is available and true"

코드 세그먼트의 이 부분에서 같은 작업의 다음 단계는 이전 단계에서 설정한 if을 사용합니다.이를 통해 사용자는 다음과 같은 작업을 수행할 수 있습니다.

Github 컨텍스트에 대한 반복 액세스 대신 플래그 재사용

하나의 조건만 사용하는 것이 아니라 여러 조건을 사용하여 플래그를 설정합니다.예를 들어 서로 다른 이유로 서로 다른 단계에서 로고를 flag 또는 true 로 설정할 수도 있다.

한 위치에서만 변수를 변경하고 여러 위치에서 변수를 변경할 필요가 없습니다

짧은 대안

커밋 설정 플래그 단계에서 다음 단계로 단순화하여 코드를 더 짧게 만들 수 있지만 반드시 더 읽을 수 있는 단계는 아닙니다.

- name: "Set flag from Commit"
  env:
    COMMIT_VAR: ${{ contains(github.event.head_commit.message, '[commit var]') }}
  run: |
    echo "::set-env name=flag::${COMMIT_VAR}"
    echo "set flag to ${COMMIT_VAR}"

활용단어참조

변수 포함

브랜치로 밀어넣기false:

> git add.
> git commit -m "Running Github Actions Test [commit var]"
> git push

워크플로우를 트리거합니다.master 제출 메시지에서 워크플로의 [commit var] 변수가 ${COMMIT_VAR}로 설정되어 다음 결과가 발생합니다.

변수 제외

브랜치로 밀어넣기true:

> git add.
> git commit -m "Running Github Actions Test"
> git push

워크플로우를 트리거합니다.master 제출 메시지에 없으므로 워크플로의 [commit var] 변수는 ${COMMIT_VAR} 로 설정되고 다음 결과가 발생합니다.

PR 바디 변수

PR을 작성할 때 PR 바디도 변수를 설정하는 데 사용할 수 있습니다.이러한 변수는 이 PR의 모든 작업 흐름에서 실행되는 데 사용될 수 있으며, 이는 제출 메시지가 더욱 정보적이고 혼란스럽지 않으며, 개발자의 업무량을 줄이는 데 도움이 된다.
다시 한 번, 이것은 예상된 키와 값입니다.이 경우 키는 false, 값은 PR_VAR 입니다.

예비 지식

요청을 특정 지점에 끌어올릴 때 트리거하기 위해 파이프 트리거를 정확하게 설치했습니다.(여기에서 우리는 마스터를 목표 지점으로 사용할 것이다.)

코드 세그먼트

on:
  pull_request:
    branches:
      - master

jobs:
  Echo-On-PR:
    runs-on: ubuntu-latest
    steps:
      - name: "Checkout Repository"
        uses: actions/checkout@v2

      - name: "Set flag from PR"
        env:
          PR_VAR: ${{ contains(github.event.pull_request.body, '[pr var]') }}
        run: |
          if ${PR_VAR} == true; then
            echo "::set-env name=flag::true"
            echo "flag set to true"
          else
            echo "::set-env name=flag::false"
            echo "flag set to false"
          fi

      - name: "Use flag if true"
        if: env.flag
        run: echo "Flag is available and true"

할 수 있다.YAMLhere.

코드 해석

YAML 파일의 첫 번째 부분은 Pull 요청 트리거만 설정합니다.다음 코드의 대부분은 같기 때문에 우리는 차이만 설명한다.

- name: "Set flag from PR"
  env:
    PR_VAR: ${{ contains(github.event.pull_request.body, '[pr var]') }}

이 절에서 [pr var] 환경 변수는 PR_VAR 또는 true 로 설정되며, 구체적으로 false 문자열이 PR 본문에 있는지에 따라 달라집니다.

짧은 대안

상기와 유사하게 YAML 단계는 코드를 더 짧게 하기 위해 다음 단계로 간소화할 수 있지만 반드시 더 읽을 수 있는 것은 아니다.

- name: "Set flag from PR"
  env:
    PR_VAR: ${{ contains(github.event.pull_request.body, '[pr var]') }}
  run: |
  echo "::set-env name=flag::${PR_VAR}"
  echo "set flag to ${PR_VAR}"

활용단어참조

[pr var] 에서 Pull 요청을 만들고 예상 변수를 본문 어딘가에 포함합니다:

Github 작업은 PR 바디에 존재하므로 master 다음과 같이 true로 설정됩니다.

실제 장면

많은 실제 장면에서 환경 변수를 제어하는 것은 매우 유용하다.개요는 다음과 같습니다.

비싼 외부 통화를 피하다

개발자 A는 통합 파이프를 작성하고 테스트하고 있습니다.집적 파이프는 Azure Data Factory나 Databricks와 같은 외부 서비스를 호출하여 결과를 기다린 후에 이 결과를 보여 주어야 한다.워크플로우는 다음과 같습니다.

작업 흐름 자체는 시간이 걸리고 실행 비용이 비싸다. 왜냐하면 Databricks 집단을 유지하고 응답을 기다려야 하기 때문이다.작업 흐름의 다른 부분을 작성하고 테스트하는 과정에서 아날로그 응답을 하고 실제 응답은 중요하지 않거나 직접 테스트하지 않은 상황에서 아날로그 응답을 함으로써 이러한 외부 의존을 없앨 수 있다.

긴 CI 프로세스 건너뛰기

개발자 B가 CI/CD 파이프라인을 작성하고 테스트하고 있습니다.파이핑에는 여러 CI 단계가 있으며 각 단계는 순차적으로 실행됩니다.워크플로우는 다음과 같습니다.

이 경우 각 CI 단계는 다음 단계가 시작되기 전에 실행되어야 하며 프로세스 중 오류로 인해 전체 파이프가 실패할 수 있습니다.경우에 따라 파이핑의 예상 동작일 수 있지만 (CI 프로세스가 실패하면 더 복잡하고 긴 구축 또는 시간이 소요되는 테스트 덮어쓰기 세트를 실행하지 않으려 할 수 있습니다.) 파이핑 자체를 테스트할 때 단계를 메모하거나 삭제해야 합니다.
반면 다른 단계에서는 제출 메시지 또는 PR 본문의 [pr var] 태그를 확인하고 CI 구축의 특정 단계를 건너뛸 수 있습니다.이렇게 하면 최종 파이프가 중단되는 변경 사항이 발생하지 않으며 주석/단계 삭제 시 발생할 수 있습니다.이 밖에 다른 절차를 뛰어넘어 단일 절차의 메커니즘을 반복적으로 테스트함으로써 파이프 개발을 더욱 쉽게 할 수 있다.