Ruby 빌드 및 테스트

소개

이 가이드에서는 Ruby 애플리케이션을 빌드하고 테스트하는 CI(연속 통합) 워크플로를 만드는 방법을 보여 줍니다. CI 테스트에 통과하면 코드를 배포하거나 gem을 게시할 수 있습니다.

필수 조건

Ruby, YAML, 워크플로 구성 옵션과 워크플로 파일을 만드는 방법을 기본적으로 이해하는 것이 좋습니다. 자세한 내용은 다음을 참조하세요.

Ruby 워크플로 템플릿 사용

빠르게 시작하려면 워크플로 템플릿을 리포지토리의 .github/workflows 디렉터리에 추가합니다.

{data variables.product.prodname_dotcom %}은(는) 대부분의 Ruby 프로젝트에 적합한 Ruby용 스타터 워크플로를 제공합니다. 이 가이드의 후속 섹션에서는 이 워크플로 템플릿을 사용자 지정하는 방법에 대한 예시를 제공합니다.

GitHub에서 리포지토리의 기본 페이지로 이동합니다.
리포지토리 이름 아래에서 작업을 클릭합니다.
리포지토리에 워크플로가 이미 있는 경우 새 워크플로를 클릭합니다.
"워크플로 선택" 페이지에는 권장되는 워크플로 템플릿의 선택 항목이 표시됩니다. "ruby"를 검색합니다.
지속적 통합을 클릭하여 워크플로 선택을 필터링합니다.
"Ruby" 워크플로에서 구성을 클릭합니다.
필요에 따라 워크플로를 편집합니다. 예를 들어 사용하려는 Ruby 버전을 변경합니다.
Note
- 워크플로 템플릿에는 GitHub에서 인증되지 않은 작업이 포함되어 있습니다. 제3자가 제공하는 작업은 별도의 서비스 약관, 개인 정보 보호 정책 및 지원 문서를 적용합니다.
- 타사의 작업을 사용하는 경우 커밋 SHA에서 지정한 버전을 사용해야 합니다. 작업을 수정하고 최신 버전을 사용하려는 경우 SHA를 업데이트해야 합니다. 태그 또는 분기를 참조하여 버전을 지정할 수 있지만 경고 없이 작업이 변경될 수 있습니다. 자세한 내용은 "GitHub Actions에 대한 보안 강화" 항목을 참조하세요.
변경 내용 커밋을 클릭합니다.

ruby.yml 워크플로 파일이 리포지토리의 .github/workflows 디렉터리에 추가됩니다.

Ruby 버전 지정

Ruby 버전을 지정하는 가장 쉬운 방법은 GitHub의 Ruby 조직에서 제공하는 ruby/setup-ruby 작업을 사용하는 것입니다. 이 작업은 워크플로에서 실행되는 각 작업에 대해 지원되는 모든 Ruby 버전을 PATH에 추가합니다. 자세한 내용 및 사용 가능한 Ruby 버전은 ruby/setup-ruby를 참조하세요.

Ruby의 ruby/setup-ruby 작업을 사용하는 것은 Ruby의 여러 실행기와 버전 간에 일관된 동작을 보장하므로 GitHub Actions와 함께 Ruby를 사용하는 데 권장되는 방법입니다.

이 setup-ruby 작업은 Ruby 버전을 입력으로 사용하고 실행기에서 해당 버전을 구성합니다.

steps:
- uses: actions/checkout@v4
- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
  with:
    ruby-version: '3.1' # Not needed with a .ruby-version file
- run: bundle install
- run: bundle exec rake

또는 .ruby-version 파일을 리포지토리의 루트로 체크 인하면 setup-ruby에서 해당 파일에 정의된 버전을 사용합니다.

여러 버전의 Ruby로 테스트

둘 이상의 Ruby 버전으로 워크플로를 실행하는 매트릭스 전략을 추가할 수 있습니다. 예를 들어 3.1, 3.0, 2.7 버전의 최신 패치 릴리스에 대해 코드를 테스트할 수 있습니다.

strategy:
  matrix:
    ruby-version: ['3.1', '3.0', '2.7']

ruby-version 배열에 지정된 Ruby의 각 버전은 동일한 단계를 실행하는 작업을 만듭니다. ${{ matrix.ruby-version }} 컨텍스트는 현재 작업의 버전에 액세스하는 데 사용됩니다. 행렬 전략 및 컨텍스트에 대한 자세한 내용은 GitHub Actions에 대한 워크플로 구문 및 워크플로 실행에 대한 컨텍스트 정보에 액세스을(를) 참조하세요.

매트릭스 전략을 사용하여 업데이트된 전체 워크플로는 다음과 같습니다.

# 이 워크플로는 GitHub에서 인증되지 않은 작업을 사용합니다.
# 작업은 타사에서 제공하며
# 별도의 서비스 약관, 개인정보처리방침, 지원 설명서에서 규정됩니다.
# 참조하세요.

# 커밋 SHA에 작업을 고정하는 것이 좋습니다.
# 최신 버전을 얻으려면 SHA를 업데이트해야 합니다.
# 태그 또는 분기를 참조할 수도 있지만 경고 없이 작업이 변경될 수 있습니다.

name: Ruby CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        ruby-version: ['3.1', '3.0', '2.7']

    steps:
      - uses: actions/checkout@v4
      - name: Set up Ruby ${{ matrix.ruby-version }}
        uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
        with:
          ruby-version: ${{ matrix.ruby-version }}
      - name: Install dependencies
        run: bundle install
      - name: Run tests
        run: bundle exec rake

번들러를 사용하여 종속성 설치

setup-ruby 작업은 자동으로 번들러를 설치합니다. 버전은 gemfile.lock 파일에 의해 결정됩니다. 잠금 파일에 버전이 없으면 호환되는 최신 버전이 설치됩니다.

steps:
- uses: actions/checkout@v4
- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
  with:
    ruby-version: '3.1'
- run: bundle install

종속성 캐싱

setup-ruby 작업은 실행 간에 gem의 캐싱을 자동으로 처리하는 메서드를 제공합니다.

캐싱을 사용하도록 설정하려면 다음을 설정합니다.

steps:
- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
  with:
    bundler-cache: true

그러면 vendor/cache에 gem을 설치하도록 번들러가 구성됩니다. 워크플로를 성공적으로 실행할 때마다 이 폴더는 GitHub Actions에 의해 캐시되고 후속 워크플로 실행을 위해 다시 다운로드됩니다. gemfile.lock 및 Ruby 버전의 해시가 캐시 키로 사용됩니다. 새 gem을 설치하거나 버전을 변경하는 경우 캐시가 유효하지 않게 되고 번들러가 새 설치를 수행합니다.

setup-ruby 없이 캐싱

캐싱에 대한 제어를 강화하기 위해 actions/cache 작업을 바로 사용할 수 있습니다. 자세한 내용은 워크플로 속도를 높이기 위한 종속성 캐싱을(를) 참조하세요.

steps:
- uses: actions/cache@v3
  with:
    path: vendor/bundle
    key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}
    restore-keys: |
      ${{ runner.os }}-gems-
- name: Bundle install
  run: |
    bundle config path vendor/bundle
    bundle install --jobs 4 --retry 3

매트릭스 빌드를 사용하는 경우 캐시 키에 매트릭스 변수를 포함해야 합니다. 예를 들어 다양한 Ruby 버전(matrix.ruby-version)과 운영 체제(matrix.os)에 대한 매트릭스 전략이 있는 경우 워크플로 단계는 다음과 같을 수 있습니다.

steps:
- uses: actions/cache@v3
  with:
    path: vendor/bundle
    key: bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby-version }}-${{ hashFiles('**/Gemfile.lock') }}
    restore-keys: |
      bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby-version }}-
- name: Bundle install
  run: |
    bundle config path vendor/bundle
    bundle install --jobs 4 --retry 3

코드 매트릭스 테스트

다음 예시 매트릭스는 Ubuntu 및 macOS에서 MRI, JRuby, TruffleRuby의 모든 안정적인 릴리스 및 헤드 버전을 테스트합니다.

# 이 워크플로는 GitHub에서 인증되지 않은 작업을 사용합니다.
# 작업은 타사에서 제공하며
# 별도의 서비스 약관, 개인정보처리방침, 지원 설명서에서 규정됩니다.
# 참조하세요.

# 커밋 SHA에 작업을 고정하는 것이 좋습니다.
# 최신 버전을 얻으려면 SHA를 업데이트해야 합니다.
# 태그 또는 분기를 참조할 수도 있지만 경고 없이 작업이 변경될 수 있습니다.

name: Matrix Testing

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ${{ matrix.os }}-latest
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu, macos]
        ruby: [2.5, 2.6, 2.7, head, debug, jruby, jruby-head, truffleruby, truffleruby-head]
    continue-on-error: ${{ endsWith(matrix.ruby, 'head') || matrix.ruby == 'debug' }}
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
        with:
          ruby-version: ${{ matrix.ruby }}
      - run: bundle install
      - run: bundle exec rake

코드 린트

다음 예시에서는 rubocop을 설치하고 이를 사용하여 모든 파일을 린트합니다. 자세한 내용은 RuboCop을 참조하세요. 특정 린팅 규칙을 결정하도록 Rubocop을 구성할 수 있습니다.

# 이 워크플로는 GitHub에서 인증되지 않은 작업을 사용합니다.
# 작업은 타사에서 제공하며
# 별도의 서비스 약관, 개인정보처리방침, 지원 설명서에서 규정됩니다.
# 참조하세요.

# 커밋 SHA에 작업을 고정하는 것이 좋습니다.
# 최신 버전을 얻으려면 SHA를 업데이트해야 합니다.
# 태그 또는 분기를 참조할 수도 있지만 경고 없이 작업이 변경될 수 있습니다.

name: Linting

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
        with:
          ruby-version: '2.6'
      - run: bundle install
      - name: Rubocop
        run: rubocop -f github

-f github를 지정하면 RuboCop 출력은 GitHub의 주석 형식이 됩니다. 모든 린팅 오류는 끌어오기 요청의 변경된 파일 탭에 인라인으로 표시됩니다.

Gems 게시

CI 테스트에 통과하면 원하는 패키지 레지스트리에 Ruby 패키지를 게시하도록 워크플로를 구성할 수 있습니다.

리포지토리 비밀을 사용하여 패키지를 게시하는 데 필요한 모든 액세스 토큰 또는 자격 증명을 저장할 수 있습니다. 다음 예시에서는 패키지를 만들고 GitHub Package Registry 및 RubyGems에 게시합니다.

# 이 워크플로는 GitHub에서 인증되지 않은 작업을 사용합니다.
# 작업은 타사에서 제공하며
# 별도의 서비스 약관, 개인정보처리방침, 지원 설명서에서 규정됩니다.
# 참조하세요.

# 커밋 SHA에 작업을 고정하는 것이 좋습니다.
# 최신 버전을 얻으려면 SHA를 업데이트해야 합니다.
# 태그 또는 분기를 참조할 수도 있지만 경고 없이 작업이 변경될 수 있습니다.

name: Ruby Gem

on:
  # Manually publish
  workflow_dispatch:
  # Alternatively, publish whenever changes are merged to the `main` branch.
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    name: Build + Publish
    runs-on: ubuntu-latest
    permissions:
      packages: write
      contents: read

    steps:
      - uses: actions/checkout@v4
      - name: Set up Ruby 2.6
        uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
        with:
          ruby-version: '2.6'
      - run: bundle install

      - name: Publish to GPR
        run: |
          mkdir -p $HOME/.gem
          touch $HOME/.gem/credentials
          chmod 0600 $HOME/.gem/credentials
          printf -- "---\n:github: ${GEM_HOST_API_KEY}\n" > $HOME/.gem/credentials
          gem build *.gemspec
          gem push --KEY github --host https://rubygems.pkg.github.com/${OWNER} *.gem
        env:
          GEM_HOST_API_KEY: "Bearer ${{secrets.GITHUB_TOKEN}}"
          OWNER: ${{ github.repository_owner }}

      - name: Publish to RubyGems
        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:
          GEM_HOST_API_KEY: "${{secrets.RUBYGEMS_AUTH_TOKEN}}"

Ruby 빌드 및 테스트

이 문서의 내용