GitHub Action JS 패키지 및 출시

🔭 개술

본고에서 ncc 패키지 도구를 사용하는 자바스크립트 GitHub 생성과 관련된 기록되지 않은 세부 사항을 공유하고 싶습니다.
이것은 순서에 따라 점진적인 지도가 아니라 문제의 이야기를 묘사하고 제기하는 방법과 배후의 추리이다.
만약 당신이 단지 빠른 코드 예시를 찾고 싶을 뿐이라면, this one 로 건너뛰고 돌아와서 설명해 주십시오🙂

🎬 네가 이미 알고 있는 기본 지식

기본 방법은 간단합니다. GitHub 문서here에 설명되어 있습니다.또한 GitHub은 간단한 JavaScript 및 TypeScript 액션 예제를 제공합니다.나는 여기서 그것을 집중적으로 토론하지 않을 것이다.

📦 ncc가 뭐예요? 왜 써요?

가장 명확하지 않고 혼란스러운 부분은 ncc 패키지 코드를 사용하는 것이다.이 단계의 필요성은 GitHub이 실행하는 방법에 의해 발생합니다.
작업이 없는 컴파일러 (용기) 는 메모리 라이브러리에서 직접 실례화하고 실행됩니다.Docker 컨테이너 작업은 매번 재구성 dockerfile 을 의미하며, 자바스크립트 작업은 node_modules 의 모든 의존항을 버전 제어 아래에 두어야 한다.
GitHub의 솔루션은 다음과 같습니다.

사용node_modules 라이브러리는 ncc에 필요한 모든 의존항과 코드를 단일 JS 파일(부품)에 포장합니다.

디렉터리가 아닌 이 파일을 제출합니다.

🤔 왜 마음에 안 드세요?

일반적으로 버전 제어 아래 구축 부품을 저장하는 것은 좋지 않은 방법으로 여겨진다.따라서 코드가 중복되고 두 복제본이 동기화됩니다.

매번 변경할 때마다 부품을 구축하고 제출하는 것을 잊지 마세요.

생성 환경과 운영 시 환경이 호환되는지 확인합니다.

모든 개발자(또는 여러 대의 기계를 사용하는 단일 개발자)는 같은 구축 환경을 가지고 같은 원본 코드에서 구축된 부품에 차이가 존재하지 않도록 해야 한다.

세 번째가 제일 문제야.나는 node_modules 압축 파일의 로컬 경로를 포함할 수 있다는 것을 발견했다. 이 파일은 로컬 컴퓨터에 대한 정보를 표시하고 서로 다른 컴퓨터에 구축할 수 있도록 한다.

💡 자동화

나는 기존의 해결 방안을 조사하고 테스트했으며 자신의 방법을 제시하여 여러분과 공유하고 싶습니다.코드나 의존항이 변경된 후에, 나는 조작을 이용하여 포장된 JS 파일을 구축하고 제출하기로 결정했다.이렇게 하면 우리는 상술한 세 가지 문제를 해결할 수 있다.다음과 같은 워크플로우를 만들겠습니다.

구축 및 패키지 단계를 수행합니다.

구축된 JS 파일이 리포

의 오래된 파일과 다르면 옵션 Hecks

해당하는 경우 새 JS 파일 제출

🚀 워크플로우 만들기

1️⃣ 먼저 표준 절차에 따라 ncc 파일을 만듭니다.

name: "build-and-pack"  
on:  
  push:  
    branches:  
      - master  
      - develop  
      - 'v\*'  

jobs:  
  build:  
    env:  
      PACKED_JS_PATH: 'dist/index.js'  
    runs-on: ubuntu-latest  
    strategy:  
      matrix:  
        node-version: [12.x]  
    steps:  
      - uses: actions/checkout@v2        
      - name: Use Node.js ${{ matrix.node-version }}  
        uses: actions/setup-node@v1  
        with:  
          node-version: ${{ matrix.node-version }}  
    ...

Defined env variable.github/workflows/build-and-pack.yml는 JS 가공소재의 대상 경로(저장소 기준)를 표시합니다.
2️⃣ 우리의 작업은 열거된 지점으로만 실행될 것입니다.이것은 PACKED_JS_PATHenv 변수(Actionsengine에서 작성)가 지점 이름을 반영한다는 것을 의미한다.단, "on push tags"이벤트를 추가하면, 태그 인용도 포함할 수 있습니다.분기 이름을 가져오려면 다음 단계를 추가합니다.

- name: Extract branch name  
  id: extractBranch  
  shell: bash  
  run: echo "##\[set-output name=branch;\]$(echo ${GITHUB\_REF#refs/heads/})"

셋️⃣ 그런 다음 의존 항목을 설치하고 TypeScript 코드를 구축하며 (사용할 경우) 원본 코드를 GITHUB_REF 로 포장하는 간단한 절차를 추가합니다.

- name: Install dependencies  
  run: npm install  
- name: Build  
  run: npm run build  
- name: Pack  
  run: npm run pack

여기의 dist/index.js 및 build 명령은 (GitHub 문서에서 권장하는 경우와 같이 pack에 정의된 스크립트일 뿐입니다.

"scripts": {  
  ...  
  "build": "tsc",  
  "pack": "ncc build",  
  ...  
}

4️⃣ 단계 추가package.json 명령을 사용하여 단계 생성/패키지화 후 변경되었는지 찾기dist/index.js:

- name: Check packed JS changes  
  id: packedJsStatus  
  run: echo ::set-output name=changes::$(git status ${{ env.PACKED\_JS\_PATH }} --porcelain)

5️⃣ 변경되면 다음과 같이 제출합니다.

- name: Commit packed JS  
  id: commitPackedJs  
  if: steps.packedJsStatus.outputs.changes  
  run: |  
    git config --local user.email "[email protected]"  
    git config --local user.name "GitHub Action"  
    git add ${{ env.PACKED_JS_PATH }}  
    git commit -m "Pack with dependencies to ${{ env.PACKED_JS_PATH }}"

6️⃣ ... 그런 다음 현재 브랜치git status 단계에서 해당 이름을 얻습니다.

- name: Push packed JS  
  if: steps.commitPackedJs.outcome == 'success'  
  uses: ad-m/github-push-action@master  
  with:  
    github\_token: ${{ secrets.GITHUB\_TOKEN }}  
    tags: true  
    force: true  
    branch: ${{ steps.extractBranch.outputs.branch }}

🏷 게시 관리

내가 하고 싶은 마지막 점은 조작에 관한 버전 제어 전략이다.이 예에서, 나는 게시를 표시하기 위해 분기를 사용한다는 것을 알 수 있습니다.
GitHubrecommends에는 레이블이 사용됩니다.만약 우리가 이렇게 한다면 우리는 반드시 기억해야 한다.

우리는 새로운 패키지 JS 파일을 제출한 후에 탭(또는 몇 개의 탭)을 이동하거나 작업 흐름이 끝난 후에 수동으로 이동해야 한다.

지점보다 관리 레이블이 더 까다롭습니다.git 명령의 다른 명령줄 옵션과 모든 GUI git 클라이언트의 not fully supported 명령줄 옵션이 필요합니다.

extractBranch 이벤트가 작업 흐름을 촉발할 때 on push tagsenv 변수는 표시ref를 가리키며 지점에 대한 정보가 없습니다.Tag ref를 목표로 변경 사항을 추진하는 것은 보통 나쁜 생각입니다.작업을 수행할 수 있지만 새 커밋은 분기와 분리되며 많은 GUI git 도구에 제대로 표시되지 않습니다.

단순화를 위해 지점을 꾸준히 관리하는 것이 좋습니다.

GIT_REF 분기는 최신 버전에 사용됩니다.

master는 지속적인 개발과 테스트에 사용되는 지점이다.

develop,v1...API 변경 중단 없이 안정적인 버전으로 분기

🏁 결말

게시를 표시하는 데 태그를 사용할 수 있지만, 작업 흐름이 끝난 후에 '패키지 의존항...' 이 제출되고 태그로 표시될 때까지 기다려야 합니다.
결과 워크플로우 파일의 예제에는 나만의 작업this one이 표시됩니다.

👏 읽어주셔서 감사합니다.

어떤 평론, 비판, 그리고 당신의 경험을 공유하더라도 감격을 금치 못할 것입니다.
만약 당신이 자신의 행동을 발전시키는 것에 관심이 있다면, 나도 당신에게 GitHub Actions Testing 시리즈를 읽는 것을 건의합니다.