Publicamos atualizações frequentes em nossa documentação, e a tradução desta página ainda pode estar em andamento. Para obter as informações mais recentes, acesse a documentação em inglês. Se houver problemas com a tradução desta página, entre em contato conosco.

Criar e testar o Ruby

É possível criar um fluxo de trabalho de integração contínua (CI) para criar e testar o seu projeto do Ruby.

GitHub Actions está disponível com GitHub Free, GitHub Pro, GitHub Free para organizações, GitHub Team, GitHub Enterprise Cloud e GitHub One. GitHub Actions não está disponível para repositórios privados pertencentes a contas usando os planos de legado por repositório.

Neste artigo

Observação: GitHub Actions estava disponível para GitHub Enterprise Server 2.22 como um beta limitado. O beta terminou. GitHub Actions está agora geralmente disponível em GitHub Enterprise Server 3.0 ou posterior. Para obter mais informações, consulte as observações sobre a versão GitHub Enterprise Server 3.0.


Observação: Executores hospedados em GitHub não são atualmente compatíveis com GitHub Enterprise Server. Você pode ver mais informações sobre suporte futuro planejado no Itinerário público do GitHub.

Introdução

Este guia mostra como criar um fluxo de trabalho de integração contínua (CI) que compila e testa um aplicativo do Rubi. Se o seu teste do CI passar, você deverá implantar seu código ou publicar um gem.

Pré-requisitos

Recomendamos que você tenha um entendimento básico do Ruby, YAML, das opções de configuração do fluxo de trabalho e de como criar um arquivo do fluxo de trabalho. Para obter mais informações, consulte:

Primeiros passos com o modelo de fluxo de trabalho do Ruby

GitHub fornece um modelo de fluxo de trabalho do Ruby que funcionará para a maioria dos projetos do Ruby. Para obter mais informações, consulte o modelo do workflow do Ruby.

Para iniciar rapidamente, adicione o modelo ao diretório .github/workflows do repositório.

name: Ruby

on:
  push:
    branches: [ $default-branch ]
  pull_request:
    branches: [ $default-branch ]

jobs:
  test:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up Ruby
      uses: ruby/setup-ruby@v1
      with:
        ruby-version: 2.6
    - name: Install dependencies
      run: bundle install
    - name: Run tests
      run: bundle exec rake

Especificar a versão do Ruby

A maneira mais fácil de especificar uma versão do Ruby é usar a ação ruby/setup-ruby fornecida pela organização Ruby no GitHub. A ação adiciona qualquer versão do Ruby compatível com PATH para cada tarefa executada em um fluxo de trabalho. Para mais informações, consulte ruby/setup-ruby.

Usar a ação ruby/setup-ruby do Ruby é a forma recomendada de usar o Ruby com o GitHub Actions porque garante um comportamento consistente entre executores diferentes e versões diferentes do Ruby.

A ação setup-ruby toma uma versão Ruby como uma entrada e configura essa versão no executor.

steps:
- uses: actions/checkout@v2
- uses: ruby/setup-ruby@v1
  with:
    ruby-version: 2.6 # Not needed with a .ruby-version file
- run: bundle install
- run: bundle exec rake

Como alternativa, você pode verificar um arquivo .ruby-version na raiz do seu repositório e setup-ruby usará a versão definida nesse arquivo.

Testar com versões múltiplas do Ruby

Você pode adicionar uma estratégia matriz para executar seu fluxo de trabalho com mais de uma versão do Ruby. Por exemplo, você pode testar o seu código para as últimas versões de correção das versões 2.7, 2.6 e 2.5. O "x" é um caractere curinga que corresponde à última versão do patch disponível para uma versão.

strategy:
  matrix:
    ruby-version: [2.7.x, 2.6.x, 2.5.x]

Cada versão do Ruby especificada no array ruby-version cria um trabalho que executa as mesmas etapas. O contexto ${{ matrix.ruby-version }} é usado para acessar a versão atual do trabalho. Para obter mais informações sobre estratégias e contextos da matriz, consulte a "Sintaxe de fluxo de trabalho para Ações no GitHub" e a "Sintaxe de Contexto e expressão para Ações no GitHub."

O fluxo de trabalho totalmente atualizado com uma estratégia de matriz pode parecer com isto:

name: Ruby CI

on:
  push:
    branches: [ $default-branch ]
  pull_request:
    branches: [ $default-branch ]

jobs:
  test:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        ruby-version: [2.7.x, 2.6.x, 2.5.x]

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

Instalar dependências com o Bundler

A ação setup-ruby irá instalar o bundler automaticamente para você. A versão é determinada pelo arquivo gemfile.lock. Se nenhuma versão estiver presente no seu arquivo de bloqueio, será instalada a última versão compatível.

steps:
- uses: actions/checkout@v2
- uses: ruby/setup-ruby@v1
  with:
    ruby-version: 2.6
- run: bundle install

Memorizar dependências

Se você estiver usando executores hospedados em GitHub, as ações do setup-ruby fornecem um método para lidar automaticamente com o cache dos seus gems entre as execuções.

Para habilitar o cache, defina o seguinte.

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

Isso irá configurar o bundler para instalar seus gems em vendor/cache. Para cada execução bem sucedida do seu fluxo de trabalho, esta pasta será armazenada em cache por Ações e baixada novamente para subsequentes execuções de fluxo de trabalho. São usados um hash do seu gemfile.lock e versão do Ruby como a chave de cache. Se você instalar qualquer novo gem, ou mudar uma versão, o cache será invalidado e o bundler fará uma nova instalação.

Fazer armazenamento em cache sem o setup-ruby

Para maior controle sobre o cache, se você estiver usando executores hospedados em GitHub, você poderá usar a ação actions/cache diretamente. Para obter mais informações, consulte "Memorizar dependências para acelerar fluxos de trabalho".

steps:
- uses: actions/cache@v2
  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

Se você estiver usando uma compilação de matriz, você vai querer incluir as variáveis da matriz na sua chave de cache. Por exemplo, se você tem uma estratégia matriz para diferentes versões do ruby (matrix. uby-version) e diferentes sistemas operacionais (matrix.os), suas etapas de fluxo de trabalho podem se parecer com isso:

steps:
- uses: actions/cache@v2
  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

Matriz que testa o seu código

O exemplo a seguir da matriz testa todas as versões estáveis e versões principais de MRI, JRuby e TruffleRuby no Ubuntu e no macOS.

name: Matrix Testing

on:
  push:
    branches: [ $default-branch ]
  pull_request:
    branches: [ $default-branch ]

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@v2
    - uses: ruby/setup-ruby@v1
      with:
        ruby-version: ${{ matrix.ruby }}
    - run: bundle install
    - run: bundle exec rake

Fazer linting do seu código

O exemplo a seguir instala rubocop e o utiliza para fazer lint de todos os arquivos. Para obter mais informações, consulte Rubocop. Pode configurar o Rubocop para decidir as regras específicas de linting.

name: Linting

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: ruby/setup-ruby@v1
      with:
        ruby-version: 2.6
    - run: bundle install
    - name: Rubocop
      run: rubocop

Publicar gems

Você pode configurar o seu fluxo de trabalho para publicar o seu pacote do Ruby em qualquer pacote de registro que você desejar quando os seus testes de CI passarem.

Você pode armazenar qualquer token de acesso ou credenciais necessárias para publicar seu pacote usando segredos do repositório. O exemplo a seguir cria e publica um pacote no Registro de Pacote do GitHub e RubyGems.


name: Ruby Gem

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

jobs:
  build:
    name: Build + Publish
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up Ruby 2.6
      uses: ruby/setup-ruby@v1
      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}}"

Esse documento ajudou você?

Privacy policy

Ajude-nos a tornar esses documentos ótimos!

Todos os documentos do GitHub são de código aberto. Você percebeu que algo que está errado ou não está claro? Envie um pull request.

Faça uma contribuição

Ou, aprenda como contribuir.