GitHub Actions는 대부분의 오픈 소스 프로젝트를 위한 CI 플랫폼으로 급부상했습니다.Travis CI의 최근 오픈 소스 가격 변경 사항은 이러한 프로세스를 더욱 가속화시킬 것입니다.
GitHub의 첫 번째 추가이기 때문에 Actions는 GitHub의 변화에 대응하기 위해 거의 무한한 잠재력을 가지고 있다.새로 연 끌어오기 요청에 대한 탭을 자동으로 설정하고 처음 제출한 참여자를 환영할 수 있습니다.
작업을 통해 수행할 수 있는 작업을 살펴보고, 마지막으로 워크플로우가 악의적인 작업자 및 악의적인 끌어오기 요청으로부터 영향을 받지 않도록 보안 관련 팁을 소개합니다.

cron 트리거 기반 작업 흐름 실행

GitHub 작업은 주어진 대량의 이벤트 here 에 응답하기 위해 작업 흐름의 실행을 촉발할 수 있습니다. 그 중 하나는cron 계획입니다.반복되는 작업을 자동화하는 데 스케줄 기능을 사용하는 방법을 살펴보겠습니다.
Android Password Store에 대해 우리는 우리가 자동으로 채운 사이트의'기본'영역을 효과적으로 측정할 수 있도록 이미 알고 있는 public suffixes 목록을 유지한다.이 목록은 자주 변경됩니다. 우리는 보통 매주 저장소를 최신 복사본과 동기화합니다.Dell은 이러한 작업을 자동화할 수 있도록 지원합니다.

name: Update Publix Suffix List data
on:
  schedule:
    - cron: '0 0 * * 6'

jobs:
  update-publicsuffix-data:
  # The actual workflow doing the update job

크론 표현식을 crontab guru에 넣으면 토요일 오전 12시에 실행되는 것을 볼 수 있습니다.APS에서 병합 풀기 요청을 확인하면 publicsuffixlist pull requests가 7일 뒤에 발생합니다.
나의 예는 매우 간단하다.cron 트리거 자동화 부분의 작업 절차를 어떻게 사용하는지 설명한다.Rust 프로젝트는 이런 같은 트리거를 사용하여 일상적인 업무에서 더욱 중요한 부분을 실현한다.Rust는 내부 컴파일러 오류(ICE) 목록과 각 오류의 코드 세션을 복제하는 glacier라는 저장소를 유지합니다.이 메모리 라이브러리는 유사한cron 트리거를 사용하여 밤마다 새로운Rust 버전을 검사하고 컴파일러 충돌이 재구성으로 묵묵히 해결되는지 확인합니다.복구된 ICE (컴파일러가 붕괴되지 않도록 정확하게 컴파일되었거나 오류가 발생했을 때) 를 만났을 때, 복사 파일을 fixed 더미로 이동하는 pull request 파일을 제출합니다.

제출 메시지 기반 작업 실행

연속적으로 납품하는 것은 좋지만, 때때로 당신은 약간의 통제를 필요로 한다.저장소로 전송될 때마다 배포 작업을 실행하는 것보다 메시지에 특정 키워드가 포함되어 있을 때만 배포 작업을 실행합니까?Actions 네이티브는 이 기능을 지원하며 사이트 배포 파이핑은 이 기능에 의존합니다.

name: Deploy to Cloudflare Workers Sites

on:
  push:
    branches:
      - main

jobs:
  deploy-main:
    if: "contains(github.event.head_commit.message, '[deploy]')"
    # Set up wrangler and push to the production environment

  deploy-staging:
    if: "contains(github.event.head_commit.message, '[staging]')"
    # Set up wrangler and push to the staging environment

이 코드 세그먼트는 메시지를 포함하는 텍스트 [deploy] 를 전송하는 맨 위에 제출할 때만 실행하고, 다른 작업은 메시지 포함 [staging] 을 제출할 때만 실행되는 작업을 정의합니다.전반적으로 말하자면, 이것들은 나로 하여금 즉시 변경 사항을 배치하고, 메인 사이트나 임시 사이트에 배치하거나, 이 두 사이트에 동시에 배치할지 여부를 통제할 수 있게 한다.그래서 현재 나는 메인 사이트를 완전히 재배치하지 않은 상태에서 초고 문장을 갱신하거나 무대에 오르지 않아도 되는 발표된 문장을 신속하게 편집할 수 있다.
이 조작의 핵심 논리는 세 부분으로 구성되어 있다.github context, if conditional와 contains 방법.모든 링크 문서는 그것들을 잘 설명하고, 더욱 높은 용례를 실현할 수 있도록 참고를 제공합니다.

여러 구성을 동시에 테스트

기본적으로 작업 흐름의 작업은 병렬로 실행됩니다. GitHub은 놀라운 행렬 기능을 제공합니다. 하나의 정의에서 여러 개의 작업을 자동으로 생성할 수 있습니다.구체적인 예를 들다.
창문.
마커스
Ubuntu
마구간
Windows+ 안정화
MacOS+ 안정
Ubuntu+ 안정화
베타
Windows+ 테스트 버전
MacOS+ 테스트 버전
Ubuntu+ 베타 버전
매일 밤
Windows+매일 밤
MacOS+매일 저녁
Ubuntu+매일 밤

_{This particular matrix is for Rust, to test a codebase across Windows, Ubuntu, and macOS using the Rust stable, beta, and nightly toolchains.}

GitHub 작업에서 우리는 단일 작업에서 플랫폼 (Windows, MacOS, Ubuntu) 과 녹슨 채널 (안정, 테스트 버전, 야간) 을 간단하게 제공하여 어떻게 배열하는지 찾아내고 단독 작업을 만들 수 있다.이러한 행렬을 구성하려면 다음과 같이 작성합니다.

jobs:
  check-rust-code:
    strategy:
      # Defines a matrix strategy
      matrix:
        # Sets the OSes we want to run jobs on
        os: [ubuntu-latest, windows-latest, macOS-latest]
        # Sets the Rust channels we want to test against
        rust: [stable, beta, nightly]
    # Make the job run on the OS picked by the matrix
    runs-on: ${{ matrix.os }}

    steps:
    - uses: actions-rs/toolchain@v1
      with:
        profile: minimal
        components: rustfmt, clippy
        # Installs the Rust toolchain for the channel picked by the matrix
        toolchain: ${{ matrix.rust }}

이것은 자동으로 9개의 (3개 플랫폼 * 3개 채널) 병행 작업을 생성하여 전체 설정을 테스트할 것입니다. 우리가 수동으로 모든 작업을 정의할 필요가 없습니다.DRY최고:)

한 가지 일을 잇달아 진행하다

기본적으로 워크플로우 파일에 정의된 작업은 동시에 실행됩니다.그러나 어떤 경우 GHA는 이 사례에 대한 지원을 포함하는 보다 질서정연한 집행 순서가 필요할 수도 있습니다.또 다른 진실한 세계의 예를 시도해 봅시다!
LeakCanary 하나는 checks job로 주 지점으로 전송될 때마다 실행됩니다.Travis CI를 최종적으로 폐기할 수 있도록 스냅샷 배포에 대한 지원을 늘리고자 합니다.이를 실현하기 위해, 나는 단지 같은 작업 흐름에 new job 하나를 추가하여, 이벤트만 실행하고, 검사 작업에 의존하도록 했다.따라서 모든 테스트가 주 지점을 통과하기 전에 스냅샷을 배치하지 않을 수 있습니다.워크플로우 구성과 관련된 부분은 다음과 같습니다.

on:
  pull_request:
  push:
    branches:
      - main

jobs:
  checks:
  # Runs automated unit and instrumentation tests

  snapshot-deployment:
  # Only run if the push event triggered this workflow run
  if: "github.event_name == 'push'"
  # Run after the 'checks' job has passed
  needs: [checks]

행동을 통해 안전 문제를 완화하다

GitHub Actions는 사용자가 작성한 조작의 활발한 생태계 덕분에 남용에 평등한 기회를 제공했다.흔히 볼 수 있는 문제를 해결하는 것은 상대적으로 쉽다. 나는 여기서 그것들을 개술할 것이다.나는 안전 방면의 권위자가 아니다. 이 건의들은 나의 읽기와 이해에 기초한 것이다.이것들은 도움이 될 것 같지만, 이 목록은 상세하지 않으니, 가능한 한 신중해야 한다.

표시가 아닌 정확한 제출 해시를 사용합니다

표시는 이동 한정자입니다. force pushed at any moment 가능합니다.워크플로우에서 작업하는 저장소가 손상되면 사용 중인 태그가 악의적인 버전에 의해 강제로 밀어붙여져 저장소 기밀이 타사 서버로 전송될 수 있습니다.주어진 표지판에서 저장소의 원본을 심사한 다음에 현재 가리키는 SHA1 제출 해시를 버전으로 사용해서 이 문제를 해결합니다. 정확한 해시로 새 제출을 위조할 수 없기 때문입니다.
특정 태그에 대한 제출 해싱을 가져오려면 저장소의 게시 페이지로 이동한 다음 태그 이름 아래의 짧은 SHA1 해싱을 클릭하고 URL에서 전체 해싱을 복사합니다.

_{Here, the commit hash is feb985e. Ideally, you want to click that link and copy the full hash from the URL}

job:
  checks:
-   - uses: burrunan/[email protected]
 +  - uses: burrunan/gradle-cache-actions@feb985ecf49f57f54f31920821a50d0394faf122

대안

이 문제에 대해 더욱 극단적인 해결 방안은 vendor 사용자가 사용하는 모든 제3자 조작을 자신의 저장소에 저장한 다음에 로컬 복사본을 원본으로 사용하는 것이다.이로써 소스 코드를 각 버전에 수동으로 동기화할 수 있지만 허용된 동작을 저장소의 작업으로 제한할 수 있어 안전성을 크게 높일 수 있습니다.그러나 만약에 업무 흐름이 대량의 제3자 조작과 관련된다면 수동 동기화는 지루해질 수 있습니다.그러나 같은 수동 동기화도 버전 간의 변화를 더욱 잘 이해할 수 있다. 왜냐하면 이것은 단독 PR 차이에서 사용할 수 있기 때문이다.
로컬 디렉토리의 작업을 사용하려면 행uses:을 저장소의 로컬 복사본의 상대 경로로 바꿉니다.

job:
  checks:
    - name: Checkout repository
    # Assuming the copy of actions/checkout is at .github/actions/checkout
-   - uses: actions/checkout@v2
+   - uses: ./.github/actions/checkout

pull 요청으로 pull 요청 목표 교체

pull_request_target github 영패에 대한 PR 접근권을 부여합니다. 이 영패는 귀하의 저장소에 기록되어 귀하의 코드를 악의적인 제3자의 수정을 받을 수 있고 악의적인 제3자는 귀하의 저장소에 대한 PR을 열기만 하면 됩니다.대다수의 사람들이 이미 금고 pull_request 사건을 사용하고 있지만, 만약 당신이 없다면 pull_request_target에 대한 요구를 검토하고 전환하십시오.

-on: [push, pull_request_target]
+on: [push, pull_request]

나는 여전히 행동을 배우고 있으며, 내가 여기에 소개하지 않은 많은 내용도 있다.GitHub 문서의 Workflow syntax와 Context and expressions syntax를 참고하여 작업 흐름 설정 기능에 대한 지식을 더 얻을 것을 강력히 권장합니다.내가 여기서 소개하지 않은 멋진 것들을 발견하면 알려주세요!