Skip to main content
Apresentado por Collin para o GoRails. Republicado na AppSignal em 19 de setembro de 2026. O Rails 8.1 vem com um executor de CI. O bin/ci executa suas verificações na sua própria máquina, orientado por um script em config/ci.rb que as novas aplicações geram para você. Um executor hospedado costuma ser mais lento do que o notebook que já está na sua frente. Em muitos projetos, a espera é a única coisa que ele acrescenta. O trabalho foi liderado por Jeremy Daer na 37signals.

​
O que este tutorial aborda

  • Ler e estender o config/ci.rb.
  • Executar a suíte com bin/ci.
  • Reportar uma execução local bem-sucedida para um pull request do GitHub.

​
Requisitos

​
O script de CI

O config/ci.rb lista os passos a executar. A versão gerada chama scripts que já estavam em bin:
  • bin/setup prepara o ambiente.
  • bin/rubocop executa verificações de estilo.
  • O Bundler Audit verifica as gems em busca de vulnerabilidades conhecidas.
  • O Importmap Audit faz o mesmo para JavaScript.
  • A suíte de testes é executada.
Nada aqui é oculto. Cada passo é um script comum em bin, legível e executável por conta própria. Um passo que falha é fácil de reproduzir isoladamente. Adicione passos para qualquer outra coisa que o seu projeto precise, e remova os que não se aplicam.

​
Executar

A saída mostra uma linha por passo, com um total ao final. Uma falha nomeia o passo que falhou, você a corrige e executa de novo. Uma execução completa e bem-sucedida em uma aplicação pequena leva algumas dezenas de segundos.

​
Aprovar um pull request

Executar o CI localmente não deixa nenhum registro no GitHub de que ele passou. A integração de aprovação adiciona esse registro: ela publica um status check na branch informando que as verificações rodaram e passaram. Instale a GitHub CLI e, depois, a extensão:
Depois, habilite o bloco de aprovação em config/ci.rb. Em uma execução bem-sucedida, ele aprova o commit e o check aparece no pull request. Em uma execução com falha, isso não acontece. Duas coisas costumam confundir na primeira vez, e ambas produzem a mesma mensagem “sign-off failed”: Ambos seguem a mesma regra: a aprovação atesta um commit que existe no remoto. Faça o commit, o push e depois execute bin/ci.

​
O que isso muda para o seu monitoramento

Mover o CI para as máquinas dos desenvolvedores remove um checkpoint que também servia como registro. O CI hospedado registra cada execução em relação a um commit; um executor local não faz isso, exceto pelo check de aprovação. Por isso, decida deliberadamente qual registro manter depois do deploy:
  • Envie um deploy marker em cada deploy. Os markers colocam uma linha nos seus gráficos no momento em que uma revisão é publicada. Eles também agrupam erros pelo deploy que os introduziu. Com o CI local, o marker é frequentemente o primeiro registro duradouro que vincula uma revisão a um horário.
  • Observe o deploy, não o build. Uma execução local verde e um servidor de build verde mostram, ambos, que suas verificações passaram no código que você tinha. Nenhum dos dois diz como o release se comportou. Compare as taxas de erros e os tempos de resposta ao redor do marker nos primeiros minutos após um deploy.
  • Mantenha as verificações honestas. O bin/ci é um script que a sua equipe pode editar. Um passo que é comentado para desbloquear alguma coisa tende a continuar comentado. Revise o config/ci.rb da mesma forma que você revisaria um arquivo de workflow.

​
Transcrição

Transcrito do vídeo e levemente editado. As legendas automáticas entenderam errado vários nomes de produtos e de APIs, e esses foram corrigidos.
0:02 Pessoal, bem-vindos a mais uma aula aqui no GoRails. E nesta, vamos explorar o CI local que agora vem com o Rails 8.1. Se você for até aquele pequeno texto que eles têm no site do Ruby on Rails.org, você pode ver um pouco sobre o CI local. Esse trabalho foi liderado por Jeremy Daer, aqui na 37signals. E a ideia é que você não precisa, sabe, de um computador na nuvem para executar sua configuração de CI, quando pode executá-la em um computador local.0:39 Isso é, em muitos casos, bem mais rápido do que executar em um computador na nuvem. Você pode ver aqui que já existe um script de CI padrão configurado para você. Ele fica em config/ci.rb e é executado pelo comando bin/ci. Aqui está esse arquivo, veja. Este é exatamente o arquivo como ele vem no Rails.1:00 E você pode ver que há uma série de passos aqui, e você pode adicionar mais se precisar. Mas já tem alguns passos básicos aqui. Mas, na verdade, tudo o que eles fazem é executar outros scripts bin que já estão na sua aplicação, que fazem coisas como configurar o ambiente de desenvolvimento, executar o RuboCop no seu código, executar o Bundler Audit, o Importmap Audit, e assim por diante. Então, como você vê aqui, ele executa os seus testes. E agora também há uma integração opcional com o GitHub, que pode aprovar pull requests para você.1:33 Digamos, ei, o CI foi executado. Este pull request está pronto para ser mesclado. Você pode ir em frente e mesclá-lo se quiser. Claro, você poderia editar essa mensagem aqui, mas essa é a padrão. E para usar isso, você também precisa instalar essa extensão da Basecamp, a extensão gh-signoff.1:49 E, veja, é bem simples aqui. Se o CI for bem-sucedido, ele vai aprovar e dizer que está tudo certo. Caso contrário, ele vai reprovar e dizer, ei, não mescle isso. Algo precisa ser corrigido primeiro. Então vamos ver isso na prática.2:03 Eu tenho uma aplicação agora em que temos esse script de CI. Por enquanto, deixei a parte do GitHub comentada. Vamos apenas executar isso e ver como fica. Certo, vou executar o comando bin/ci aqui. E vamos ver que ele vai executar todos aqueles passos definidos naquele arquivo config/ci.rb.2:22 Você pode ver aqui que tivemos uma falha. Eu volto para isso em um segundo. Alguma coisa com o Importmap Audit falhou por algum motivo, vamos dar uma olhada nisso. Então, aqui embaixo, você vê essa única falha que tivemos, então a integração contínua falhou em 20,23 segundos, o que é bem rápido. E se rolarmos para cima de novo, vemos aqui essa única falha nossa.2:44 Há uma auditoria de vulnerabilidade do Importmap que falhou. Então podemos dar uma olhada nisso e ver qual é o problema. Podemos corrigir isso no nosso código e depois executar o CI de novo. Vou fazer isso agora.2:57 Certo, então foi assim que passamos na nossa auditoria do Importmap. Então isso é bom. Devemos estar tudo certo a partir daqui, porque acredito que essa foi a única falha que tivemos. Temos alguns avisos de duplicação aqui, mas ok, agora podemos ver que, nesta execução, a integração contínua passou.3:14 Então isso é bom para nós localmente. Mas e se precisarmos comunicar isso no GitHub? Vamos abrir um pull request. Então eu fiz uma modificação para atualizar o readme desse código, nada demais. Vamos usar isso só como exemplo para executar o CI.3:27 Então, para usar as coisas do gh-signoff, de novo, vamos precisar ter essa GitHub CLI instalada e instalar essa extensão da Basecamp. Eu já tenho a GitHub CLI instalada. Posso mostrar isso executando gh aqui, e podemos ver que essa é, de fato, a CLI do GitHub. Então a única coisa que precisamos instalar é essa extensão aqui, que eu ainda não tenho instalada. Vamos copiar esse comando e executá-lo.3:53 Então vamos instalar essa extensão gh-signoff da Basecamp. Certo, muito bem. Então isso está feito. E agora vamos descomentar a condicional aqui. Certo, salvar isso.4:05 E agora vamos executar nosso CI de novo aqui. Agora que o CI foi executado desta vez, vemos que a aprovação falhou. E o motivo é que, embora eu tenha criado uma branch para atualizar o readme aqui, temos alterações não commitadas e não enviadas localmente. Então precisamos primeiro commitar essas coisas. Vou dar uma olhada rápida no git status aqui.4:27 E então, sim, está tudo certo. Vamos adicionar tudo isso e commitar. Vamos dizer atualização do readme e habilitação da GitHub CLI no CI. Certo, agora temos um bom commit. Deveria estar tudo certo aqui.4:46 E agora vamos executar o comando bin/ci de novo. E vamos ver o que acontece esta vez. Certo, falhou de novo. Commitamos as nossas alterações, mas ainda não as enviamos. Então vemos aqui que isso provavelmente se encaixa naquela categoria de que ainda temos alterações não enviadas.5:02 Então vamos enviar isso. Vou abrir isso aqui. E depois vamos apenas adicionar uma descrição. É um teste bem simples do novo CI local no Rails 8.1. Então vamos criar um pull request aqui.5:15 Então vamos executar bin/ci de novo aqui. Vamos ver o que acontece. Certo, agora, dessa vez, vemos que, agora que commitamos as alterações e as enviamos, temos essa aprovação bem-sucedida aqui. Então vemos que ele aprovou o commit aqui. E então recebemos a mensagem, sabe, aprovação concedida, todos os sistemas prontos para mesclagem e deploy, passou em, sabe, 0,8 segundos, integração contínua no geral passou em 23,37 segundos.5:43 E agora, se voltarmos ao GitHub aqui e rolarmos para baixo nessa seção, se olharmos na seção de checks, podemos realmente ver que o check de aprovação foi, sabe, enviado para a branch aqui. Ele diz que foi aprovado, e temos o check. Então está tudo certo, né? Agora que esse CI local foi executado, podemos usar isso em combinação com a GitHub CLI para aprovar checks e dizer, sabe, ei, executamos isso localmente, tudo passou com sucesso, e estamos prontos para mesclar. Então, na verdade, não precisaríamos fazer nada disso de novo.6:20 Porque já fizemos tudo isso localmente. Não precisamos fazer isso de novo, sabe, no CI do GitHub aqui. Então, coisa bem legal. Depois que tudo está coordenado, essa coisa de aprovação é bem interessante. E também, sabe, todo esse código aqui no script de CI é algo que você pode executar, sabe, você mesmo, e estender, e ir conferir, sabe, você pode olhar qualquer um desses arquivos, os scripts que já estão configurados na sua aplicação Rails.6:44 Então o RuboCop. Eles estão todos no diretório bin na sua aplicação Rails, já ali. Sabe, as coisas do Bundler, você também pode executar você mesmo. Mas, quer dizer, está tudo ali, disponível. Se precisar ver esse código, você pode simplesmente ir a qualquer um desses arquivos em bin, e você vê que eles estão todos ali.7:01 Por exemplo, tem um setup, o RuboCop bem acima dele. O Bundler Audit está ali também. Então, coisas bem legais aqui com a novidade do CI local no Rails 8.1. Então, com certeza, eu diria para você conferir, ver se funciona para você. Você talvez consiga simplificar parte da sua configuração de CI e simplesmente passar a usar isso, e talvez adicionar o que precisar, ou remover o que não precisar, do jeito que quiser, sabe?7:26 Então, com isso, espero que você tenha gostado desta aula, e te vejo na próxima.

​
Sobre este tutorial

Este tutorial resume um screencast do GoRails sobre o CI local no Rails 8.1, apresentado por Collin. O screencast é o trabalho original. O GoRails o publica, junto com o resto da série, em gorails.com.