Usando o Chrome para corrigir o erro do arquivo DevToolsActivePort no Selenium nas ações do GitHub

Superando falhas de teste do Chrome em pipelines de CI/CD

Executando testes Selenium em cromo sem cabeça sobre Ações do GitHub deve ser perfeito. Mesmo assim, muitos desenvolvedores enfrentam o frustrante erro “O arquivo DevToolsActivePort não existe”. Isso acontece quando o Chrome, por um motivo ou outro, não consegue iniciar corretamente no ambiente de CI.

A mensagem de erro geralmente indica que o Chrome está travando inesperadamente, o que geralmente é resultado de incompatibilidades Cromo e ChromeDriver versões ou opções mal configuradas na configuração de teste. Como muitos desenvolvedores, encontrei esse desafio, principalmente ao implantar testes automatizados em um ambiente integração contínua ambiente.

Nessa configuração, o menor desalinhamento, como uma incompatibilidade de versão do ChromeDriver, pode interromper a execução do teste, custando tempo e recursos valiosos. Felizmente, compreender os problemas subjacentes torna a resolução muito mais fácil 🛠️.

Neste guia, abordaremos as etapas práticas para prevenir e solucionar esse erro comum. Desde as especificações de instalação do Chrome até a inicialização adequada do driver, você encontrará um processo passo a passo para garantir sempre a execução de testes sem problemas. Vamos resolver esse problema e colocar seus testes de volta nos trilhos!

Solução detalhada para configuração do Chrome e ChromeDriver no CI

Os scripts acima foram projetados para instalar e configurar o Chrome e o ChromeDriver em Ações do GitHub ambientes, abordando especificamente o erro "O arquivo DevToolsActivePort não existe". Esse problema normalmente ocorre quando o Chrome, executado no modo headless, não consegue iniciar corretamente devido a incompatibilidades ou restrições de memória. O primeiro script aborda isso especificando uma versão do Chrome e garantindo sua compatibilidade com o ChromeDriver, o que é crucial para a execução Selênio testes. Os comandos iniciais realizam uma atualização dos pacotes apt e usam wget para buscar uma versão específica do Google Chrome de um espelho. Usar um espelho garante que a versão correta seja instalada, especialmente se o repositório padrão não tiver essa versão. Essa abordagem garante que uma versão consistente do Chrome seja usada em diferentes execuções de testes.

Em seguida, o script instala um ChromeDriver compatível com a versão, isolando a versão principal do Chrome (por exemplo, "117" de "117.0.5938.62") usando um comando para analisá-lo. Isso permite que o script busque o ChromeDriver exato necessário para aquela versão principal específica usando um padrão de URL projetado para versões do ChromeDriver. Ao garantir que essas versões estejam alinhadas, a configuração evita que versões incompatíveis causem falha na inicialização do ChromeDriver, o que geralmente aciona o erro do DevTools. Se o ChromeDriver não conseguir baixar a versão específica, o script incluirá uma opção alternativa para baixar a versão mais recente, mantendo a flexibilidade. Essas etapas são particularmente úteis em pipelines automatizados de CI/CD, onde soluções rápidas e confiáveis ​​são uma prioridade 🔧.

Após o download, o script exclui do sistema qualquer ChromeDriver instalado anteriormente usando “sudo rm -f” para evitar conflitos com drivers mais antigos. Isso garante que apenas a versão correta esteja em vigor, minimizando os riscos de conflitos de versão que podem atrapalhar a estabilidade do teste. As permissões para ChromeDriver também são definidas para serem executáveis, o que é uma etapa necessária para iniciar o driver em ambientes CI/CD. Usar o Chrome no modo “sem cabeça” com opções como “--no-sandbox” e “--disable-dev-shm-usage” também reduz o consumo de recursos do Chrome. Essas opções permitem que os testes sejam executados em ambientes com recursos limitados (por exemplo, servidores em nuvem ou pipelines de CI) sem causar falhas no Chrome, que é uma das causas comuns por trás do erro DevToolsActivePort.

Finalmente, na configuração do WebDriver, opções como “--disable-gpu” e “--remote-debugging-port=9222” garantem uma execução mais estável do Chrome no modo headless. O sinalizador “--disable-gpu” desativa a renderização da GPU, o que é desnecessário e às vezes problemático no modo headless. Enquanto isso, a opção “--remote-debugging-port” permite que o Chrome abra uma porta de depuração essencial para o Selenium se conectar a ela no CI. Em suma, esta configuração evita gargalos comuns de automação, permitindo um ambiente de teste mais confiável e robusto. Como resultado, esses scripts tornam a execução do Chrome headless em sistemas CI/CD uma experiência muito mais tranquila, garantindo que os testes automatizados sejam executados de forma consistente e sem problemas 🚀.

sudo apt-get update
sudo apt-get install -y wget apt-transport-https curl
CHROME_VERSION="117.0.5938.62"
CHROME_DEB="google-chrome-stable_${CHROME_VERSION}-1_amd64.deb"
wget https://mirror.cs.uchicago.edu/google-chrome/pool/main/g/google-chrome-stable/$CHROME_DEB
sudo dpkg -i $CHROME_DEB || sudo apt-get install -f -y
# Install ChromeDriver matching Chrome
sudo apt-get install -y wget unzip
MAJOR_VERSION=$(echo $CHROME_VERSION | cut -d '.' -f1)
LATEST_DRIVER=$(wget -qO- https://chromedriver.storage.googleapis.com/LATEST_RELEASE_$MAJOR_VERSION)
if [ -z "$LATEST_DRIVER" ]; then
  echo "Falling back to latest ChromeDriver version."
  LATEST_DRIVER=$(wget -qO- https://chromedriver.storage.googleapis.com/LATEST_RELEASE)
fi
sudo rm -f /usr/local/bin/chromedriver
wget https://chromedriver.storage.googleapis.com/$LATEST_DRIVER/chromedriver_linux64.zip
unzip chromedriver_linux64.zip
sudo mv chromedriver /usr/local/bin/
sudo chmod +x /usr/local/bin/chromedriver

// Import necessary libraries
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import io.github.bonigarcia.wdm.WebDriverManager;
// Set up ChromeDriver
WebDriverManager.chromedriver().setup();
ChromeOptions options = new ChromeOptions();
options.addArguments("--no-sandbox");
options.addArguments("--disable-dev-shm-usage");
options.addArguments("--headless");
options.addArguments("--disable-gpu");
options.addArguments("--remote-debugging-port=9222");
ChromeDriver driver = new ChromeDriver(options);
// Start Selenium test logic here
driver.quit();

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;
class WebDriverTests {
  private WebDriver driver;
  @BeforeEach
  void setUp() {
    ChromeOptions options = new ChromeOptions();
    options.addArguments("--headless");
    options.addArguments("--no-sandbox");
    driver = new ChromeDriver(options);
  }
  @Test
  void testDriverInitialization() {
    driver.get("https://www.google.com");
    assertEquals("Google", driver.getTitle());
  }
  @AfterEach
  void tearDown() {
    driver.quit();
  }
}

Otimizando testes Selenium com GitHub Actions e Headless Chrome

Um aspecto importante da corrida cromo sem cabeça com Selenium em pipelines de CI/CD como GitHub Actions é compreender as restrições ambientais. Executar o Chrome no modo headless significa que ele opera sem interface gráfica, tornando-o perfeito para ambientes de CI. No entanto, o Chrome headless pode ser mais sensível às configurações do sistema e requer configuração adicional em comparação com um ambiente local. O erro “O arquivo DevToolsActivePort não existe” está comumente associado a uma falha na inicialização do Chrome, geralmente devido a restrições de memória ou incompatibilidades de configuração. Implementando configurações com uso eficiente de memória, como --disable-dev-shm-usage e --no-sandbox ajuda a superar esses problemas e pode estabilizar significativamente os testes em ambientes CI/CD com memória limitada.

Para garantir a compatibilidade, é essencial manter as versões do Chrome e do ChromeDriver alinhadas. Versões inconsistentes são uma fonte frequente de erros em GitHub Actions, pois o executor pode usar como padrão a versão mais recente, que pode não atender aos requisitos do ChromeDriver. Para resolver isso, nossa solução inclui analisar a versão principal do Chrome para buscar a versão exata do ChromeDriver correspondente, melhorando a estabilidade. Além disso, definir porta de depuração remota permite que o ChromeDriver interaja com o navegador de maneira mais confiável, ativando uma porta de comunicação. Esta configuração é essencial ao usar GitHub Actions ou ferramentas semelhantes para executar ações automatizadas testes de navegador em uma máquina virtual.

Essas configurações fazem uma grande diferença na eficiência, reduzindo erros e melhorando a confiabilidade das execuções de testes. Ao garantir opções eficientes em termos de recursos e usar as versões corretas, as execuções headless do Chrome têm muito mais probabilidade de serem executadas com sucesso, evitando que os desenvolvedores enfrentem erros frustrantes no meio do teste. Em última análise, configurações robustas e dependências compatíveis tornam a experiência de teste de CI/CD mais tranquila, permitindo que os desenvolvedores se concentrem na criação e melhoria de seus aplicativos sem a interrupção de problemas persistentes de configuração 🚀.