GitHub 운영 자동화 Ruby Gem 릴리스

당신이 보석 유지 보수 기계든 보석 창작 세계를 막 접한 사람이든 이 강좌는 당신에게 적합합니다.SemVer를 고수하고 업데이트된 변경 로그를 유지하는 것은 양호한 기원을 유지하는 중요한 구성 부분이지만 때로는 고통이기도 하다.이 자습서는 Ruby gem의 작고 중요한 부분을 자동화하는 간단한 게시 프로세스를 안내합니다.

석방해 주십시오

Release Please Action는 구글이 만든 GitHub 조작으로 Conventional Commit Messages를 통해 자동으로 발표하는 데 사용된다.PR을 기본 분기에 결합하면 해당 분기는 변경 로그에 자동으로 커밋을 추가하고 커밋에 따라 버전을 수정하는 새 게시 분기를 작성/업데이트합니다.결합 PR은 변경 내용을 게시할 준비가 되면 새 GitHub 버전을 작성하고 게시합니다.우리는 심지어 가방 등록 센터에 자동으로 발표할 수 있다. 예를 들어RubyGems!

일반적인 승낙

본문은 당신이 익숙하다고 가정합니다Conventional Commits.다음은 the action's README에서 추출한 중요한 접두사에 대한 간략한 개술이다.
당신이 기억해야 할 가장 중요한 접두사는:

fix: 오류가 수정되었으며 SemVer 패치와 관련이 있음을 나타냅니다.

feat: 새 피쳐를 나타내며 SemVer 단조와 연관됩니다.

feat!:, 또는 fix!:,refactor!: 등은 하나의 돌파적인 변화를 대표한다(유래반은 일하고 반은 공부하는 전공을 초래할 것이다.

나는 비교적 긴 문장을 써서 업무 절차에서 전통적인 제출 정보를 어떻게 사용하는지 소개할 것을 고려하고 있으니, 만약 당신이 이것에 대해 흥미가 있다면 저에게 알려주십시오.

테스트

이 작업의 기능을 설명하기 위해 새gem을 만들 것입니다.

bundler gem release-please-demo --test=rspec --ci=github
cd release-please-demo
bundle install

Skip to the bottom if you'd just like to see the result!

다음에 Gem를 발표하려면 Gempec를 업데이트해야 합니다.나는 지금 이 문제를 토론할 생각은 없지만, 만약 당신이 Ruby gem 규범을 어떻게 설정하는지에 대한 정보를 더 알고 싶다면, 나는 checking out this great article by Piotr Murach를 건의합니다.
이것이 바로 나의 release-please-demo.gemspec 모습이다.

# frozen_string_literal: true

require_relative "lib/release/please/demo/version"

Gem::Specification.new do |spec|
  spec.name = "release-please-demo"
  spec.version = Release::Please::Demo::VERSION
  spec.authors = ["Andrew Mason"]
  spec.email = ["[email protected]"]
  spec.summary = "Demo of release-please."
  spec.description = "A demo gem showing how to use release-please to automatically version gems."
  spec.homepage = "https://github.com/andrewmcodes/release-please-demo"
  spec.license = "MIT"
  spec.required_ruby_version = Gem::Requirement.new(">= 2.4.0")
  spec.metadata = {
    "bug_tracker_uri" => "#{spec.homepage}/issues",
    "changelog_uri" => "#{spec.homepage}/blob/main/CHANGELOG.md",
    "documentation_uri" => spec.homepage.to_s,
    "homepage_uri" => spec.homepage.to_s,
    "source_code_uri" => spec.homepage.to_s
  }

  spec.files = Dir.chdir(File.expand_path(__dir__)) do
    `git ls-files -z`.split("\x0").reject { |f| f.match(%r{\A(?:test|spec|features)/}) }
  end
  spec.bindir = "exe"
  spec.executables = spec.files.grep(%r{\Aexe/}) { |f| File.basename(f) }
  spec.require_paths = ["lib"]
end

본 논문의 목적은 발표 주기에 주목하는 것이기 때문에, Bundler가 구축한gem을 사용할 것입니다. 코드 변경은 없습니다.자신의gem를 구축하고 있다면, 이것은gem에 기능을 추가할 부분입니다.

행동을 설정하다

EMC 의 발표 전략 구축:

touch .github/workflows/release.yml

선택한 코드 편집기에서 이것을 엽니다.
우선, 우리는 작업의 이름과 실행 시간을 설정해야 한다.이 작업은 워크플로우에 따라 일부 컨텐트를 기본 분기 또는 게시 분기로 병합할 때만 실행되기를 원합니다.기본 지점을main이라고 명명하기 때문에 코드gems를main으로 전송할 때마다 이 동작을 실행합니다.

# .github/workflows/release.yml

name: release

on:
  push:
    branches:
      - main

다음에 우리는 Release Please Action에 숙제를 설치해야 한다.옵션 설명에는 설명이 있지만 view the official configuration documentation 자세한 내용을 참조하십시오.

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: GoogleCloudPlatform/release-please-action@v2
        id: release
        with:
          # The release type
          release-type: ruby
          # A name for the artifact releases are being created for
          # which is the name of our gem
          package-name: release-please-demo
          # Should breaking changes before 1.0.0 produce minor bumps?
          bump-minor-pre-major: true
          # Path to our version file to increment
          version-file: "lib/release/please/demo/version.rb"

우리는 1초 안에 더 멋진 일을 할 것이지만, 이것이 무슨 일이 일어날지 계속 봅시다.새로운 GitHub 재구매 계약을 작성하여 모든 내용을 제출하고 확대합니다.주의해야 할 것은 Bundler가 gm을 구축할 때 기본적으로 실패한 테스트 조건을 추가합니다. 따라서 gm을 만들 때 --ci=github 로고를 추가하면 생성된 .github/workflows/main.yml 작업은 실패한 테스트를 삭제하지 않으면 실패합니다.내가 지금 니가 직접 디버깅하라고.
변경 사항을 주 지점으로 밀어넣으면 발표 작업이 실행됩니다.당신의 초기 달리기 출력은 다음과 같아야 합니다.

Run GoogleCloudPlatform/release-please-action@v2
✖ No merged release PR found
✖ Unable to build candidate
✔ found 4 commits since beginning of time
✖ no user facing commits found since beginning of time

출력 표시:

통합된 게시 PR을 찾을 수 없습니다. 나중에 논의하겠습니다

구축 후보 없음

환매 협의에서 4가지 약속 발견

이러한 제출은 모두 사용자를 위한 것이 아니다. 즉, 기능이나 오류 복구가 아니라는 것이다

참조 전용 - 이 출력은 git log --one-line입니다. 따라서 4개의 제출을 볼 수 있습니다.

9a4d62b (HEAD -> main, origin/main) build: add release action (#1)
1b0bcd4 chore: bundle install
7a30c6d chore: update gemspec
c793bca chore: initial commit

보시다시피 아무런 기능이나 수정이 없기 때문에 이 작업은 발표 PR을 만들지 않았습니다.

게시 작성

나는 하나의 특성에 대해 사기와 빈 제출을 진행할 것이다.

git commit --allow-empty -m "feat: add a feature"
git push -u origin main

게시 작업을 실행해야 합니다. 이번에 제출을 마주한 사용자를 찾아서 새 게시 PR을 엽니다. PR은 버전 번호를 추가하고 기존 변경 로그를 새로 만들거나 편집합니다.

주의: 이전 버전이 없는gem에 대해서는 전체 버전의 발표를 막을 방법을 찾을 수 없습니다.통합하기 전에 원하는 초기 버전 번호와 일치하도록 PR을 편집하고 발표할 수 있습니다.이것은 이전 버전의 항목을 가진 문제가 아니다.

RubyGems에 게시

만약 우리가 변경 로그의 생성과 버전 제어만 자동화하고 싶다면, 현재의 설정은 매우 좋으나, 버전이 발표된 후에도, 우리는gem를 스스로 발표해야 한다.다행히도 우리는 기존의 작업 절차에 연결하여 발표 자동화를 실현할 수 있습니다!
우리의 첫 번째 id는 release 라는 것을 알 수 있습니다.이렇게 하면 우리는 다른 단계에서 이 단계의 출력을 검사하고 이에 상응하여 행동을 취할 수 있다.

단계 설정

게시 단계의 출력이 release_created인 경우 리포를 체크 아웃하고 Ruby를 설치한 다음 실행bundle install합니다.

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: GoogleCloudPlatform/release-please-action@v2
        id: release
        with:
          release-type: ruby
          package-name: release-please-demo
          bump-minor-pre-major: true
          version-file: "lib/release/please/demo/version.rb"
      # Checkout code if release was created
      - uses: actions/checkout@v2
        if: ${{ steps.release.outputs.release_created }}
      # Setup ruby if a release was created
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.0.0
        if: ${{ steps.release.outputs.release_created }}
      # Bundle install
      - run: bundle install
        if: ${{ steps.release.outputs.release_created }}

게시 단계

게시되면 Gem 자격 증명을 설정하고 Gem을 구축하여 Ruby Gems로 전송합니다.
get an API token from RubyGems와add it to your repository secrets가 필요합니다.나는 내 이름 RUBYGEMS_AUTH_TOKEN 을 붙였지만, 너는 원하는 대로 이름을 설정할 수 있다.

- name: publish gem
  run: |
    mkdir -p $HOME/.gem
    touch $HOME/.gem/credentials
    chmod 0600 $HOME/.gem/credentials
    printf -- "---\n:rubygems_api_key: ${GEM_HOST_API_KEY}\n" > $HOME/.gem/credentials
    gem build *.gemspec
    gem push *.gem
  env:
    # Make sure to update the secret name
    # if yours isn't named RUBYGEMS_AUTH_TOKEN
    GEM_HOST_API_KEY: "${{secrets.RUBYGEMS_AUTH_TOKEN}}"
  if: ${{ steps.release.outputs.release_created }}

주의: 나는 직접 GitHub's action documentation에서 이 코드를 얻었다.

발포

우리의 마지막 행동:

# .github/workflows/release.yml

name: release

on:
  push:
    branches:
      - main

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: GoogleCloudPlatform/release-please-action@v2
        id: release
        with:
          release-type: ruby
          package-name: release-please-demo
          bump-minor-pre-major: true
          version-file: "lib/release/please/demo/version.rb"
      # Checkout code if release was created
      - uses: actions/checkout@v2
        if: ${{ steps.release.outputs.release_created }}
      # Setup ruby if a release was created
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.0.0
        if: ${{ steps.release.outputs.release_created }}
      # Bundle install
      - run: bundle install
        if: ${{ steps.release.outputs.release_created }}
      # Publish
      - name: publish gem
        run: |
          mkdir -p $HOME/.gem
          touch $HOME/.gem/credentials
          chmod 0600 $HOME/.gem/credentials
          printf -- "---\n:rubygems_api_key: ${GEM_HOST_API_KEY}\n" > $HOME/.gem/credentials
          gem build *.gemspec
          gem push *.gem
        env:
          # Make sure to update the secret name
          # if yours isn't named RUBYGEMS_AUTH_TOKEN
          GEM_HOST_API_KEY: "${{secrets.RUBYGEMS_AUTH_TOKEN}}"
        if: ${{ steps.release.outputs.release_created }}

이 코드를 제출하고 전송하며 게시 PR이 업데이트될 때까지 저희 action bot에서 기다립니다.릴리즈 PR을 업데이트한 후 PR을 주 브랜치에 결합합니다.

게시 작업이 실행되면 GitHub에서 새로운 게시를 볼 수 있습니다.이 작업의 중요한 특징 중 하나는 변경 로그 항목에 따라 발행 설명을 생성하는 것입니다.🚀

만약 우리가 Ruby Gems를 본다면, 우리는 우리의 새로운 창업 보드가 이미 발표되고 공유될 준비가 되어 있음을 보게 될 것이다.

마지막 생각

만약 당신이 강좌를 따르고 새로운 보석을 사용하지 않으려면 다른 사람들이 미래에 이 이름을 사용할 수 있도록 뽑아야 한다.

gem yank release-please-demo -v 1.0.0

이 작업의 중요한 부분 중 하나는 다른 언어나 .txt 파일과 함께 사용할 수 있고 모든 오픈 소스 코드에서 일치하는 패턴을 만들 수 있다는 것이다.게시하기 전에 테스트를 실행할 수 있도록 검사를 추가할 수 있고, 일반적인 제출을 사용할 수 있도록 linter를 추가할 수 있습니다.이 작업 절차가 있으면, 코드를 뜯을 필요도, 프로젝트를 다시 시도하고 기억할 필요도 없이, 새로운 버전을 쉽게 발표할 수 있다.
해봐, 네 생각을 말해줘!