Crear y probar en Ruby

Introducción

Esta guía te muestra cómo crear un flujo de trabajo de integración contínua (IC) que cree y pruebe una aplicación de Ruby. Si tus pruebas de IC pasan, podrías querer desplegar tu código o publicar una gema.

Prerrequisitos

Te recomendamos que tengas una comprensión básica de Ruby, YAML, las opciones de configuración de flujo de trabajo y de cómo crear un archivo de flujo de trabajo. Para más información, consulte:

Uso de una plantilla de flujo de trabajo de Ruby

Para comenzar rápidamente, agregue una plantilla de flujo de trabajo al directorio .github/workflows del repositorio.

GitHub proporciona una la plantilla de flujo de trabajo para Ruby que debería funcionar para la mayoría de los proyectos de Ruby. En las secciones siguientes de esta guía se proporcionan ejemplos de cómo puede personalizar esta plantilla de flujo de trabajo.

En GitHub, navegue hasta la página principal del repositorio.
En el nombre del repositorio, haz clic en Acciones.
Si ya tiene un flujo de trabajo en su repositorio, haga clic en New workflow (Nuevo flujo de trabajo).
En la página "Elegir un flujo de trabajo" se muestra una selección de plantillas de flujo de trabajo recomendadas. Busca "Ruby".
Filtra la selección de flujos de trabajo con un clic en Integración continua.
En el flujo de trabajo «Ruby», haz clic en Configurar.
Edita el flujo de trabajo según sea necesario. Por ejemplo, cambia las versiones de Ruby que desea usar.
Note
- Esta la plantilla de flujo de trabajo contiene una acción que no está certificada por GitHub. Las acciones que proporciona un tercero se rigen por términos de servicio, directivas de privacidad y documentación externos.
- Si usas acciones de terceros, debes usar una versión especificada por un SHA de confirmación. Si se revisa la acción y deseas usar la versión más reciente, deberás actualizar el SHA. También puedes especificar a una etiqueta o rama, pero la acción puede cambiar sin ninguna advertencia. Para obtener más información, vea «Fortalecimiento de seguridad para GitHub Actions».
Haga clic en Commit changes (Confirmar cambios).

Especificar la versión de Ruby

La forma más sencilla de especificar una versión de Ruby consiste en usar la acción ruby/setup-ruby que se proporciona en la organización de Ruby en GitHub. La acción agrega cualquier versión compatible con Ruby a PATH de cada ejecución de un trabajo en un flujo de trabajo. Para más información y obtener las versiones de Ruby disponibles, vea ruby/setup-ruby.

El uso de la acción ruby/setup-ruby de Ruby es la forma recomendada de utilizar Ruby con Acciones de GitHub, ya que esto garantiza el comportamiento consistente entre los diversos ejecutores y versiones de Ruby.

La acción setup-ruby toma una versión de Ruby como entrada y la configura en el ejecutor.

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

Como alternativa, puede insertar un archivo .ruby-version en la raíz del repositorio y setup-ruby usará la versión definida en ese archivo.

Hacer pruebas con varias versiones de Ruby

Puedes agregar una estrategia de matriz para ejecutar tu flujo de trabajo con más de una versión de Ruby. Pro ejemplo, puedes probar tu código contra los últimos lanzamientos de parche de las versiones 3.1, 3.0 y 2.7.

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

Cada versión de Ruby que se especifica en la matriz ruby-version crea un trabajo que ejecuta los mismos pasos. El contexto ${{ matrix.ruby-version }} se usa para acceder a la versión del trabajo actual. Para más información sobre las estrategias y contextos de matriz, consulta Sintaxis del flujo de trabajo para Acciones de GitHub y Acceso a información contextual sobre ejecuciones de flujo de trabajo.

El flujo de trabajo ya actualizado en su totalidad con una estrategia de matriz podría verse así:

# Este flujo de trabajo usa acciones que no GitHub no certifica.
# Estas las proporcionan entidades terceras y las gobiernan
# condiciones de servicio, políticas de privacidad y documentación de soporte
# en línea.

# GitHub recomienda anclar acciones a un SHA de confirmación.
# Para obtener una versión más reciente, debes actualizar el SHA.
# También puedes hacer referencia a una etiqueta o rama, pero la acción puede cambiar sin ninguna advertencia.

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

Instalar dependencias con Bundler

La acción setup-ruby instalará automáticamente el empaquetador. La versión viene determinada por el archivo gemfile.lock. Si no hay alguna versión presente en tu archivo de bloqueo, entonces se instalará la última versión compatible.

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

Almacenar dependencias en caché

Las acciones setup-ruby proporcionan un método para controlar automáticamente el almacenamiento en caché de las gemas entre ejecuciones.

Para habilitar el guardado en caché, configura lo siguiente.

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

Esto configurará el empaquetador para instalar las gemas en vendor/cache. Para cada ejecución correcta de tu flujo de trabajo, GitHub Actions almacenará esta carpeta en caché y volverá a descargarse para cualquier ejecución de flujo de trabajo posterior. Se utiliza un hash de tu gemfile.lock y de la versión de Ruby como la clave de caché. Si instalas cualquier gema nueva o cambias una versión, el caché se invalidará y bundler realizará una instalación desde cero.

Almacenamiento en caché sin setup-ruby

Para tener mayor control sobre el almacenamiento en caché, puedes usar la acción actions/cache directamente. Para más información, consulta Almacenar en caché las dependencias para agilizar los flujos de trabajo.

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

Si estás utilizando una compilación de matriz, deberás incluir las variables de dicha matriz en tu clave de caché. Por ejemplo, si tiene una estrategia de matriz para diferentes versiones de Ruby (matrix.ruby-version) y sistemas operativos (matrix.os), los pasos de flujo de trabajo podrían tener este aspecto:

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

Probar tu código en matrices

La siguiente matriz de ejemplo prueba todos los lanzamientos estables y versiones principales de MRI, JRuby y TruffleRuby en Ubuntu y macOS.

# Este flujo de trabajo usa acciones que no GitHub no certifica.
# Estas las proporcionan entidades terceras y las gobiernan
# condiciones de servicio, políticas de privacidad y documentación de soporte
# en línea.

# GitHub recomienda anclar acciones a un SHA de confirmación.
# Para obtener una versión más reciente, debes actualizar el SHA.
# También puedes hacer referencia a una etiqueta o rama, pero la acción puede cambiar sin ninguna advertencia.

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

Limpiar tu código

En el ejemplo siguiente se instala rubocop y se usa para el lint de todos los archivos. Para más información, vea RuboCop. Puede configurar Rubocop para decidir las reglas de linting específicas.

# Este flujo de trabajo usa acciones que no GitHub no certifica.
# Estas las proporcionan entidades terceras y las gobiernan
# condiciones de servicio, políticas de privacidad y documentación de soporte
# en línea.

# GitHub recomienda anclar acciones a un SHA de confirmación.
# Para obtener una versión más reciente, debes actualizar el SHA.
# También puedes hacer referencia a una etiqueta o rama, pero la acción puede cambiar sin ninguna advertencia.

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

Especificar -f github significa que la salida de RuboCop estará en el formato de anotación de GitHub. Los errores de linting se mostrarán en línea en la pestaña Archivos modificados de la solicitud de incorporación de cambios que los introduce.

Publicar gemas

Puedes configurar tu flujo de trabajo para publicar tu paquete de Ruby en cualquier registro de paquetes que quieras cuando pasen tus pruebas de IC.

Puedes almacenar todos los tokens de acceso o credenciales necesarios para publicar tu paquete utilizando secretos del repositorio. En el ejemplo siguiente se crea y publica un paquete en GitHub Package Registry y RubyGems.

# Este flujo de trabajo usa acciones que no GitHub no certifica.
# Estas las proporcionan entidades terceras y las gobiernan
# condiciones de servicio, políticas de privacidad y documentación de soporte
# en línea.

# GitHub recomienda anclar acciones a un SHA de confirmación.
# Para obtener una versión más reciente, debes actualizar el SHA.
# También puedes hacer referencia a una etiqueta o rama, pero la acción puede cambiar sin ninguna advertencia.

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}}"

Crear y probar en Ruby

En este artículo