GitHub에서 변경 로그 및 게시 작성 자동화

변경 로그를 업데이트하고 GitHub 버전을 생성하는 것은 내가 줄곧 중요하게 생각했던 임무 중 하나였지만, 주어진 프로젝트에서 수동으로 실행하는 횟수가 많을수록 이것은 자질구레한 일이 되었다고 생각한다.최근의 OSS 프로젝트 camper에서 변경 로그를 수동으로 생성하지 않기로 결정했고 GitHub에서 정보를 발표했습니다.
다른 선택을 연구한 후에 나는 github-changelog-generator에 올랐다.이것은 레이블, 문제, 합병 요청에 따라 변경 로그를 자동으로 생성할 수 있는 깔끔한 프로젝트입니다.

# 구현
이 프로젝트를 GitHub에 호스팅하기 때문에 저는 GitHub Actions을 CI 프로세스의 일부로 실시했습니다.이것은 행동을 실천에 옮기고 그것을 익힐 수 있는 기회이다.이 글은 GitHub 작업에 대한 소개가 아니라 Actions Docs을 살펴보고 이 주제를 어떻게 시작하고 깊이 있게 연구하는지 알아보는 것이다.
벌써 돌아왔어!!다행이네요. 디테일하게 들어갈게요.
우선, 내가 생각한 주요 요구에 대해 토론해 봅시다.main 지사로 제출:

은 새로운 업데이트 변경 로그를 생성하여 main에 제출해야 한다.이는 합병된 PRs와 main에 대한 어떠한 직접적인 약속도 설명할 것이다.

게시된 레이블에 포함되지 않은 모든 최신 변경 사항은 변경 로그

맨 위에 게시되지 않은 섹션으로 그룹화해야 합니다.
새 탭을 밀어넣을 때:

변경 로그를 업데이트하여 게시되지 않은 모든 변경 사항을 새 태그로 이동합니다.

에서 최신 변경 로그 태그 항목과 관련된 모든 정보를 포함하는 새로운 GitHub release을 만듭니다.

CI - 변경 로그 워크플로우 #
이전 절에서 설명한 바와 같이 변경 로그 업데이트 과정은 두 부분으로 구성된다.하나는 main으로 통합되었을 때, 다른 하나는 새 탭을 전송할 때였다.아래와 같이 CI-Changelog 작업 흐름은 main지점으로 전송될 때마다 Changelog를 업데이트하는 요구를 충족시켰다.너는 here에서 최신 버전을 찾을 수 있다

name: CI - Changelog

on:
  push:
    branches: [main]

jobs:
  changelog_prerelease:
    name: Update Changelog For Prerelease
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
        with:
          ref: main
      - name: Update Changelog
        uses: heinrichreimer/[email protected]
        with:
          token: $
          issues: true
          issuesWoLabels: true
          pullRequests: true
          prWoLabels: true
          unreleased: true
          addSections: '{"documentation":{"prefix":" **Documentation:**","labels":["documentation"]}}'
      - uses: stefanzweifel/git-auto-commit-action@v4
        with:
          commit_message: Update Changelog for PR
          file_pattern: CHANGELOG.md

다음과 같이 작동합니다.

action/checkout v2

검사 코드 사용

은 다음과 같은 사용자 정의 설정이 있는 heinrichreimer/github-changelog-generator-action 작업을 사용하여 변경 로그의 업데이트를 계속 생성합니다.

체크아웃된 모든 문제는 변경 로그의 일부여야 합니다. 태그가 없는 질문(issues: true 및 issuesWoLabels: true)

모든 인출 요청은 변경 로그의 일부여야 합니다. 태그가 없는 요청(pullRequests: true 및 prWoLabels: true)

모든 최신 변경 사항을 미발표 부분으로 분류해야 한다(unreleased: true)

새로운 문서 섹션을 추가하여 documentation 태그

으로 질문과 요청을 그룹화합니다.

그리고 stefanzweifel/git-auto-commit-action 작업

을 사용하여 수정된 변경 로그 파일을main에 제출

게시 워크플로우 #
게시 작업 흐름은 변경 로그를 업데이트할 뿐만 아니라, 새gem버전과 전송 중인 태그와 관련된 새 GitHub의 게시도 처리하기 때문에 더욱 복잡한 파이프라인이다.본 논문에서 우리는 Changelog와 GitHub 발표와 관련된 업무에만 관심을 기울인다.관심 있는 경우 전체 워크플로우 here을 참조하십시오.

name: Release

on:
  push:
    tags:
      - v*

jobs:
# Other jobs
# ...
  changelog:
    name: Update Changelog
    runs-on: ubuntu-latest
    steps:
      - name: Get version from tag
        env:
          GITHUB_REF: $
        run: |
          export CURRENT_VERSION=${GITHUB_TAG/refs\/tags\/v/}
          echo "::set-env name=CURRENT_VERSION::$CURRENT_VERSION"
      - name: Checkout code
        uses: actions/checkout@v2
        with:
          ref: main
      - name: Update Changelog
        uses: heinrichreimer/[email protected]
        with:
          token: $
          issues: true
          issuesWoLabels: true
          pullRequests: true
          prWoLabels: true
          addSections: '{"documentation":{"prefix":" **Documentation:**","labels":["documentation"]}}'
      - uses: stefanzweifel/git-auto-commit-action@v4
        with:
          commit_message: Update Changelog for tag $
          file_pattern: CHANGELOG.md

  release_notes:
    name: Create Release Notes
    runs-on: ubuntu-latest
    needs: changelog
    steps:
      - name: Get version from tag
        env:
          GITHUB_REF: $
        run: |
          export CURRENT_VERSION=${GITHUB_TAG/refs\/tags\/v/}
          echo "::set-env name=CURRENT_VERSION::$CURRENT_VERSION"

      - name: Checkout code
        uses: actions/checkout@v2
        with:
          ref: main

      - name: Get Changelog Entry
        id: changelog_reader
        uses: mindsers/changelog-reader-action@v1
        with:
          version: $
          path: ./CHANGELOG.md

      - name: Create Release
        id: create_release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: $ # This token is provided by Actions, you do not need to create your own token
        with:
          tag_name: $
          release_name: Release $
          body: $
          draft: false
          prerelease: false

첫 번째 작업 업데이트 Changelog는 이전 섹션에서 설명한 것과 거의 같습니다.차이점은 발표 버전만 생성하기 때문에 unreleased: true 항목이 없다는 것이다.
두 번째는 다음과 같은 방법으로 릴리즈 노트를 작성하는 것입니다.

은 업데이트된 변경 로그에 의존하기 때문에 needs: changelog의 존재로 인해 이전의 changelog 작업이 완성되기를 기다리게 된다.

은 mindsers/changelog-reader-action을 사용하여 전송된 라벨과 관련된 변경 로그 항목을 계속 선택합니다.

은 actions/create-release을 사용하고 이전

에서 추출한changelog 항목의 내용을 GitHub 버전으로 생성합니다

GitHub action gotchas #
changelog generator 작업에서 쉽게 발견할 수 없는 문제가 있습니다.

업데이트 변경 로그 단계에서 지정한 대부분의 옵션, 예를 들어 issues: true과 pullRequests: true은 기본 truegem에서 기본값은 github-changelog-generator이지만 작업의 일부분으로 필요하지 않으면 false으로 설정합니다.이것은 나로 하여금 한동안 곤혹스럽게 했다. 내가 이 행동의 실시를 읽을 때까지, 특히 entrypoint.sh

여러 단어로 접두사를 지정하는 경우(예: changelog generator wiki 제안된 문서 업데이트) addSections 필드를 사용하여 새 섹션을 추가하는 데 실패합니다.문제는 entrypoint.sh의 분사에 있다. 예를 들어 issue#3이 말한 바와 같다.

변경 로그 생성기 제한 #changelog-generator gem에서 생성된 출력을 반복할 때 나는 문제와 관련된 PRs 사이에서 두 개의 항목(즉 병합할 때 문제의 PRs를 닫는 것)을 얻었다는 것을 깨달았다.나는 파일에서 문제를 표시하거나 홍보할 방법을 찾으려고 뒤적였지만 소용이 없었다.그리고 나는github 환매 협의에 issue을 발표했고 나의 의심을 증명했다. 즉,github REST API의 제한으로 인해 현재 이 점을 실현할 수 없다는 것이다.

결론
이 문서에서 Changelog와 GitHub 버전을 자동으로 만드는 방법에 대해 논의했습니다.각 워크플로에 대해 자세히 설명하고 워크플로에 관련된 각 작업의 단계를 설명합니다.우리는github 조작과 github-changelog-generatorgem의 일부 제한과 결함도 언급했다.
마지막으로 본문을 읽어 주셔서 감사합니다.너도 나처럼 그것을 즐겨 읽기를 바란다.안녕히 계세요.