GitHub Actions para proteger su flujo de trabajo

El desarrollo moderno es tan complejo, que es imposible tenerlo todo en cuenta (sobre todo, las distintas recomendaciones para escribir código). Aquí es donde los linters vienen al rescate. Permiten conservar determinados estándares en el proyecto y mantener en orden la base de código.

En Evrone, desarrollamos proyectos en una amplia variedad de lenguajes de programación (como Ruby, Go, Rust, Python, Elixir, etc.) y conectamos distintos linters a cada proyecto. Para asegurarnos de que el código cumpla con todos los estándares de calidad, ejecutamos linters mediante servicios de CI para todas las confirmaciones de código que enviamos a GitHub.

Reviewdog

Para nosotros, es muy importante que el resultado del trabajo de linters siempre sea visible en GitHub (por ejemplo, en forma de comentarios para solicitudes de incorporación de cambios). Para hacerlo, usamos reviewdog, que automatiza la revisión de código y proporciona una integración fluida de cualquier linter con GitHub. Por esto creemos que reviewdog es tan bueno:

• Está escrito en Go, y se puede compilar en un archivo binario conectado a cualquier proyecto, independientemente del lenguaje de programación.
• Funciona con cualquier linter; solo hay que redirigir el resultado del linter a la entrada de reviewdog y definir el formato de salida del linter, por ejemplo:$ dotenv-linter | reviewdog -efm="%f:%l %m"
• Admite un gran número de linters de forma predeterminada, como dotenv-linter, rubocop y otros.

GitHub Actions

Aunque creemos que reviewdog es genial, teníamos que dedicar tiempo a configurar servicios de CI para ejecutar linters para cada proyecto. Pero todo eso cambió cuando GitHub anunció GitHub Actions, una nueva herramienta para automatizar flujos de trabajo. En resumen, se trata de un completo servicio de CI/CD con excelentes funciones que permite crear sus propias acciones y compartirlas con la comunidad.

Al cambiar a GitHub Actions, decidimos escribir nuestras propias acciones para ejecutar linters populares. Al hacerlo, podíamos simplificar el proceso de conectar linters a cualquier proyecto. Esto es lo que conseguimos:

• action-rubocop
• action-brakeman
• action-reek
• action-fasterer
• action-hadolint
• action-dotenv-linter

Todas nuestras acciones pueden publicar comentarios de linter de dos modos.

1. Como una anotación en el código (github-pr-check)

2.Y en la forma de comentarios para solicitudes de incorporación de cambios(github-pr-review)

Ruby Actions

Las primeras 4 acciones (action-rubocop, action-brakeman, action-reek y action-fasterer) permiten ejecutar linters populares de la comunidad de Ruby: rubocop, brakeman, reek,y fasterer. Para conectar estas acciones a su proyecto, solo tiene que crear un archivo .github/workflows/linters.yml con el siguiente contenido:

# .github/workflows/linters.yml
name: linters
on: [pull_request]
jobs:
  linters:
    name: runner / linters
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v1
      - name: rubocop
        uses: reviewdog/action-rubocop@v1
        with:
          rubocop_version: gemfile
          rubocop_extensions: rubocop-rails:gemfile rubocop-rspec:gemfile
          github_token: ${{ secrets.github_token }}
      - name: brakeman
        uses: reviewdog/action-brakeman@v1
        with:
          brakeman_version: gemfile
          github_token: ${{ secrets.github_token }}
      - name: reek
        uses: reviewdog/action-reek@v1
        with:
          reek_version: gemfile
          github_token: ${{ secrets.github_token }}
      - name: fasterer
        uses: vk26/action-fasterer@v1
        with:
          github_token: ${{ secrets.github_token }}

Para action-rubocop, action-brakeman y action-reek, se puede especificar la versión de linter. Hay 3 opciones disponibles:

• Un valor vacío o ninguna versión: se instalará la última versión.
• gemfile se instalará la versión de Gemfile.lock.
• 1.0.0 se instalará la versión especificada.

Action-rubocop también permite instalar extensiones adicionales. Las extensiones siguientes se instalan de forma predeterminada: rubocop-rails, rubocop-performance, rubocop-rspec, rubocop-i18n, rubocop-rake. But this can be overridden using the rubocop_extensionsattribute.

Dockerfile Action

La siguiente acción (action-hadolint) busca todas las instancias de Dockerfile en el proyecto y las comprueba con el linter hadolint. Ejemplo de uso:

# .github/workflows/hadolint.yml
name: hadolint
on: [pull_request]
jobs:
  hadolint:
    name: runner / hadolint
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v1
      - name: hadolint
        uses: reviewdog/action-hadolint@v1
        with:
          github_token: ${{ secrets.github_token }}
          hadolint_ignore: DL3008

Dotenv-linter Action

Por último, pero no menos importante, tenemos action-dotenv-linter. Permite comprobar fácilmente todos los archivos .env del proyecto. Ejemplo de uso:

# .github/workflows/dotenv_linter.yml
name: dotenv-linter
on: [pull_request]
jobs:
  dotenv-linter:
    name: runner / dotenv-linter
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v1
      - name: dotenv-linter
        uses: dotenv-linter/action-dotenv-linter@v2
        with:
          github_token: ${{ secrets.github_token }}
          dotenv_linter_flags: --skip UnorderedKey

Encontrará más ejemplos de GitHub Actions en la página GitHub Marketplace . Póngase en contacto con nosotros si necesita ayuda para desarrollar su proyecto.