Utilisation de Chrome pour corriger l'erreur de fichier DevToolsActivePort dans Selenium sur les actions GitHub

Surmonter les échecs des tests Chrome dans les pipelines CI/CD

Exécution de tests Selenium dans Chrome sans tête sur Actions GitHub devrait être transparent. Pourtant, de nombreux développeurs sont confrontés à l’erreur frustrante « Le fichier DevToolsActivePort n’existe pas ». Cela se produit lorsque Chrome, pour une raison ou une autre, ne démarre pas correctement dans l'environnement CI.

Le message d'erreur signale généralement que Chrome plante de manière inattendue, ce qui est souvent le résultat d'une non-concordance. Chrome et Pilote Chrome versions ou options mal configurées dans la configuration de test. Comme beaucoup de développeurs, j'ai rencontré ce défi, notamment lors du déploiement de tests automatisés dans un intégration continue environnement.

Dans cette configuration, le moindre désalignement, comme une incompatibilité de version de ChromeDriver, peut interrompre l'exécution des tests, ce qui coûte du temps et des ressources précieuses. Heureusement, comprendre les problèmes sous-jacents facilite grandement leur résolution 🛠️.

Dans ce guide, nous aborderons les étapes pratiques pour prévenir et résoudre cette erreur courante. Des spécificités de l'installation de Chrome à l'initialisation correcte du pilote, vous trouverez un processus étape par étape pour garantir un test fluide à chaque fois. Abordons ce problème et remettons vos tests sur les rails !

Solution détaillée pour la configuration de Chrome et ChromeDriver dans CI

Les scripts ci-dessus sont conçus pour installer et configurer Chrome et ChromeDriver sur Actions GitHub environnements, traitant spécifiquement de l'erreur « Le fichier DevToolsActivePort n'existe pas ». Ce problème se produit généralement lorsque Chrome, exécuté en mode sans tête, ne peut pas démarrer correctement en raison de discordances ou de contraintes de mémoire. Le premier script résout ce problème en spécifiant une version de Chrome et en garantissant sa compatibilité avec ChromeDriver, ce qui est crucial pour exécuter Sélénium essais. Les commandes initiales effectuent une mise à jour des packages apt et utilisent wget pour récupérer une version spécifique de Google Chrome à partir d'un miroir. L'utilisation d'un miroir garantit que la bonne version est installée, surtout si le référentiel par défaut ne dispose pas de cette version. Cette approche garantit qu'une version cohérente de Chrome est utilisée lors de différentes exécutions de tests.

Ensuite, le script procède à l'installation d'un ChromeDriver compatible avec la version en isolant la version majeure de Chrome (par exemple, "117" de "117.0.5938.62") à l'aide d'une commande pour l'analyser. Cela permet au script de récupérer le ChromeDriver exact nécessaire pour cette version majeure spécifique à l'aide d'un modèle d'URL conçu pour les versions de ChromeDriver. En s'assurant que ces versions s'alignent, la configuration empêche les versions incompatibles de provoquer l'échec de l'initialisation de ChromeDriver, qui déclenche souvent l'erreur DevTools. Si ChromeDriver ne parvient pas à télécharger la version spécifique, le script inclut une option de secours pour télécharger la dernière version, tout en conservant la flexibilité. Ces étapes sont particulièrement utiles dans les pipelines CI/CD automatisés où des solutions rapides et fiables sont une priorité 🔧.

Après le téléchargement, le script supprime tout ChromeDriver précédemment installé du système à l'aide de « sudo rm -f » pour éviter les conflits avec les anciens pilotes. Cela garantit que seule la version correcte est en place, minimisant ainsi les risques de conflits de versions pouvant perturber la stabilité des tests. Les autorisations pour ChromeDriver sont également définies pour être exécutables, ce qui est une étape nécessaire pour lancer le pilote dans les environnements CI/CD. L'utilisation de Chrome en mode « sans tête » avec des options telles que « --no-sandbox » et « --disable-dev-shm-usage » réduit également l'empreinte des ressources de Chrome. Ces options permettent d'exécuter des tests dans des environnements avec des ressources limitées (par exemple, des serveurs cloud ou des pipelines CI) sans provoquer le crash de Chrome, ce qui est l'une des causes courantes de l'erreur DevToolsActivePort.

Enfin, dans la configuration de WebDriver, des options telles que « --disable-gpu » et « --remote-debugging-port=9222 » garantissent un fonctionnement plus stable de Chrome en mode sans tête. L'indicateur « --disable-gpu » désactive le rendu GPU, ce qui est inutile et parfois problématique en mode sans tête. Pendant ce temps, l'option « --remote-debugging-port » permet à Chrome d'ouvrir un port de débogage essentiel pour que Selenium puisse s'y connecter dans CI. En résumé, cette configuration évite les goulots d'étranglement courants de l'automatisation, permettant ainsi un environnement de test plus fiable et plus robuste. En conséquence, ces scripts rendent l'exécution de Chrome sans tête sur les systèmes CI/CD une expérience beaucoup plus fluide, garantissant que les tests automatisés s'exécutent de manière cohérente et sans problème 🚀.

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();
  }
}

Optimisation des tests Selenium avec les actions GitHub et Chrome sans tête

Un aspect important de la course à pied Chrome sans tête avec Selenium dans les pipelines CI/CD comme GitHub Actions, c'est comprendre les contraintes environnementales. L'exécution de Chrome en mode sans tête signifie qu'il fonctionne sans interface graphique, ce qui le rend parfait pour les environnements CI. Cependant, Chrome sans tête peut être plus sensible aux configurations du système et nécessite une configuration supplémentaire par rapport à un environnement local. L'erreur « Le fichier DevToolsActivePort n'existe pas » est généralement liée à un échec d'initialisation de Chrome, souvent dû à des contraintes de mémoire ou à des incohérences de configuration. Implémentation de configurations économes en mémoire comme --disable-dev-shm-usage et --pas de bac à sable aide à surmonter ces problèmes et peut stabiliser considérablement les tests dans les environnements CI/CD à mémoire limitée.

Pour garantir la compatibilité, il est essentiel de maintenir les versions de Chrome et de ChromeDriver alignées. Les versions incohérentes sont une source fréquente d'erreurs dans les actions GitHub, car le programme d'exécution peut utiliser par défaut la dernière version, qui peut ne pas correspondre aux exigences de ChromeDriver. Pour résoudre ce problème, notre solution inclut l'analyse de la version majeure de Chrome pour récupérer la version exacte de ChromeDriver qui correspond, améliorant ainsi la stabilité. De plus, le réglage port de débogage distant permet à ChromeDriver d'interagir avec le navigateur de manière plus fiable en activant un port de communication. Cette configuration est essentielle lors de l'utilisation de GitHub Actions ou d'outils similaires pour exécuter automatiquement tests de navigateur sur une machine virtuelle.

Ces configurations font une grande différence en termes d'efficacité, réduisant les erreurs et améliorant la fiabilité des tests. En garantissant des options économes en ressources et en utilisant les versions correctes, les exécutions sans tête de Chrome sont beaucoup plus susceptibles de s'exécuter avec succès, évitant ainsi aux développeurs de faire face à des erreurs frustrantes en cours de test. En fin de compte, des configurations robustes et des dépendances compatibles rendent l'expérience de test CI/CD plus fluide, permettant aux développeurs de se concentrer sur la création et l'amélioration de leurs applications sans être perturbés par des problèmes de configuration persistants 🚀.