Chrome gebruiken om de DevToolsActivePort-bestandsfout in Selenium op GitHub-acties op te lossen

Chrome-testfouten in CI/CD-pijplijnen overwinnen

Selenium-tests uitvoeren op moet naadloos zijn. Toch worden veel ontwikkelaars geconfronteerd met de frustrerende foutmelding 'DevToolsActivePort-bestand bestaat niet'. Dit gebeurt wanneer Chrome om de een of andere reden niet goed opstart in de CI-omgeving.

De foutmelding geeft meestal aan dat Chrome onverwacht crasht, wat vaak het gevolg is van niet-overeenkomende En versies of verkeerd geconfigureerde opties in de testopstelling. Zoals veel ontwikkelaars ben ik deze uitdaging tegengekomen, vooral bij het implementeren van geautomatiseerde tests in een omgeving.

In deze opzet kan de kleinste foutieve uitlijning, zoals het niet overeenkomen van de ChromeDriver-versie, de testuitvoering tot stilstand brengen, wat kostbare tijd en middelen kost. Gelukkig maakt het begrijpen van de onderliggende problemen het oplossen ervan veel gemakkelijker 🛠️.

In deze handleiding duiken we in de praktische stappen om deze veelvoorkomende fout te voorkomen en op te lossen. Van de installatiegegevens van Chrome tot de juiste initialisatie van het stuurprogramma: u vindt hier een stapsgewijs proces om keer op keer voor soepele testuitvoeringen te zorgen. Laten we dit probleem aanpakken en uw tests weer op de rails krijgen!

Commando	Voorbeeld van gebruik
CHROME_VERSION="117.0.5938.62"	Stelt een specifieke Chrome-versie in, essentieel voor het garanderen van ChromeDriver-compatibiliteit tijdens CI-tests om mismatches tussen Chrome en ChromeDriver te voorkomen.
MAJOR_VERSION=$(echo $CHROME_VERSION | cut -d '.' -f1)	Extraheert het hoofdversienummer uit de volledige Chrome-versie. Dit wordt gebruikt om een ​​overeenkomende versie van ChromeDriver te downloaden, waardoor compatibiliteit wordt gegarandeerd.
LATEST_DRIVER=$(wget -qO- ...)	Haalt de nieuwste compatibele ChromeDriver-versie op voor de opgegeven Chrome-versie, essentieel om “DevToolsActivePort”-fouten in automatiseringsscripts te voorkomen.
if [ -z "$LATEST_DRIVER" ]	Controleert of de ChromeDriver-versievariabele leeg is, wat zou duiden op een fout bij het ophalen van een compatibele versie. Deze voorwaarde helpt bij het toepassen van een fallback om testfouten te voorkomen.
sudo dpkg -i $CHROME_DEB	Installeert het gedownloade Chrome-pakket met dpkg, wat vooral handig is in Linux-omgevingen zoals GitHub Actions.
sudo rm -f /usr/local/bin/chromedriver	Verwijdert alle eerder geïnstalleerde ChromeDriver. Dit zorgt ervoor dat er geen versieconflict ontstaat tijdens de nieuwe installatie.
options.addArguments("--no-sandbox")	Schakelt de Chrome-sandboxfunctie uit. Dit is vooral belangrijk in CI-omgevingen, omdat sandboxing kan voorkomen dat Chrome in de headless-modus opstart.
options.addArguments("--disable-dev-shm-usage")	Vergroot het beschikbare gedeelde geheugen door het gebruik van /dev/shm uit te schakelen, wat Chrome-crashes kan voorkomen in omgevingen met beperkt geheugen, zoals containers.
options.addArguments("--remote-debugging-port=9222")	Maakt foutopsporing op afstand mogelijk op een opgegeven poort. Dit is een vereiste voor headless Chrome om in sommige omgevingen correct te kunnen werken, waardoor "DevToolsActivePort"-fouten worden voorkomen.
driver.quit()	Sluit alle Chrome-vensters en beëindigt de WebDriver-sessie, waardoor bronnen vrijkomen. Dit is essentieel in CI/CD-pijplijnen om lekken van bronnen te voorkomen en te voorkomen dat er onvoldoende geheugen beschikbaar is.

Gedetailleerde oplossing voor Chrome en ChromeDriver-installatie in CI

De bovenstaande scripts zijn ontworpen om zowel Chrome als ChromeDriver te installeren en configureren omgevingen, waarbij specifiek de fout "DevToolsActivePort-bestand bestaat niet" wordt aangepakt. Dit probleem treedt meestal op wanneer Chrome, uitgevoerd in de headless-modus, niet goed kan starten vanwege niet-overeenkomende instellingen of geheugenbeperkingen. Het eerste script pakt dit aan door een Chrome-versie te specificeren en de compatibiliteit ervan met ChromeDriver te garanderen, wat cruciaal is voor het draaien testen. De initiële commando's voeren een update uit van apt-pakketten en gebruiken wget om een ​​specifieke versie van Google Chrome uit een mirror op te halen. Het gebruik van een mirror zorgt ervoor dat de juiste versie wordt geïnstalleerd, vooral als de standaardrepository deze versie niet heeft. Deze aanpak garandeert dat er bij verschillende testruns een consistente versie van Chrome wordt gebruikt.

Vervolgens gaat het script verder met het installeren van een versie-compatibele ChromeDriver door de hoofdversie van Chrome te isoleren (bijvoorbeeld "117" van "117.0.5938.62") met behulp van een opdracht om deze te parseren. Hierdoor kan het script de exacte ChromeDriver ophalen die nodig is voor die specifieke hoofdversie met behulp van een URL-patroon dat is ontworpen voor ChromeDriver-releases. Door ervoor te zorgen dat deze versies op één lijn liggen, voorkomt de configuratie dat niet-overeenkomende versies de initialisatiefout van ChromeDriver veroorzaken, wat vaak de DevTools-fout veroorzaakt. Als ChromeDriver er niet in slaagt de specifieke versie te downloaden, bevat het script een terugvaloptie om de nieuwste release te downloaden, waardoor de flexibiliteit behouden blijft. Deze stappen zijn met name handig in geautomatiseerde CI/CD-pijplijnen waar snelle en betrouwbare oplossingen prioriteit hebben 🔧.

Na het downloaden verwijdert het script alle eerder geïnstalleerde ChromeDriver van het systeem met behulp van "sudo rm -f" om conflicten met oudere stuurprogramma's te voorkomen. Dit zorgt ervoor dat alleen de juiste versie beschikbaar is, waardoor de risico's van versieconflicten die de teststabiliteit kunnen verstoren, worden geminimaliseerd. Machtigingen voor ChromeDriver zijn ook uitvoerbaar ingesteld, wat een noodzakelijke stap is voor het starten van het stuurprogramma in CI/CD-omgevingen. Het gebruik van Chrome in de ‘headless’-modus met opties als ‘--no-sandbox’ en ‘--disable-dev-shm-usage’ verkleint ook de voetafdruk van Chrome. Met deze opties kunnen tests worden uitgevoerd in omgevingen met beperkte bronnen (bijvoorbeeld cloudservers of CI-pijplijnen) zonder dat Chrome crasht, wat een van de meest voorkomende oorzaken is van de DevToolsActivePort-fout.

Ten slotte zorgen opties als “--disable-gpu” en “--remote-debugging-port=9222” in de WebDriver-installatie voor een stabielere uitvoering van Chrome in de headless-modus. De vlag “--disable-gpu” schakelt GPU-rendering uit, wat onnodig en soms problematisch is in de headless-modus. Ondertussen zorgt de optie “--remote-debugging-port” ervoor dat Chrome een debugging-poort kan openen die essentieel is voor Selenium om er verbinding mee te maken in CI. Kortom, deze opzet voorkomt veel voorkomende knelpunten in de automatisering, waardoor een betrouwbaardere en robuustere testomgeving mogelijk wordt. Als gevolg hiervan zorgen deze scripts ervoor dat het gebruik van Chrome zonder hoofd op CI/CD-systemen een veel soepelere ervaring wordt, waardoor geautomatiseerde tests consistent en zonder haperingen worden uitgevoerd 🚀.

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

Selenium-tests optimaliseren met GitHub-acties en Headless Chrome

Een belangrijk aspect van hardlopen met Selenium in CI/CD-pijplijnen zoals GitHub begrijpt Actions de milieubeperkingen. Als Chrome in de headless-modus wordt uitgevoerd, werkt het zonder grafische interface, waardoor het perfect is voor CI-omgevingen. Headless Chrome kan echter gevoeliger zijn voor systeemconfiguraties en vereist aanvullende instellingen vergeleken met een lokale omgeving. De fout 'DevToolsActivePort-bestand bestaat niet' wordt vaak in verband gebracht met een fout in de initialisatie van Chrome, vaak als gevolg van geheugenbeperkingen of niet-overeenkomende configuraties. Het implementeren van geheugenefficiënte configuraties zoals En helpt deze problemen te overwinnen en kan tests in CI/CD-omgevingen met beperkt geheugen aanzienlijk stabiliseren.

Om compatibiliteit te garanderen, is het essentieel om zowel de Chrome- als de ChromeDriver-versie op één lijn te houden. Inconsistente versies zijn een frequente bron van fouten in GitHub Actions, omdat de runner mogelijk standaard de nieuwste versie gebruikt, die mogelijk niet overeenkomt met de ChromeDriver-vereisten. Om dit aan te pakken, omvat onze oplossing het parseren van de belangrijkste Chrome-versie om de exacte corresponderende ChromeDriver-versie op te halen, waardoor de stabiliteit wordt verbeterd. Bovendien, instelling zorgt ervoor dat ChromeDriver betrouwbaarder met de browser kan communiceren door een communicatiepoort in te schakelen. Deze configuratie is essentieel bij het gebruik van GitHub Actions of soortgelijke tools om geautomatiseerd uit te voeren op een virtuele machine.

Deze configuraties maken een groot verschil in efficiëntie, verminderen fouten en verbeteren de betrouwbaarheid van testruns. Door te zorgen voor hulpbronnenefficiënte opties en door de juiste versies te gebruiken, is de kans veel groter dat headless Chrome-uitvoeringen succesvol worden uitgevoerd, waardoor ontwikkelaars niet te maken krijgen met frustrerende fouten tijdens het testen. Uiteindelijk zorgen robuuste configuraties en compatibele afhankelijkheden ervoor dat de CI/CD-testervaring soepeler verloopt, waardoor ontwikkelaars zich kunnen concentreren op het maken en verbeteren van hun applicaties zonder de verstoring van aanhoudende installatieproblemen 🚀.

1. Wat betekent de foutmelding "DevToolsActivePort-bestand bestaat niet"?
2. Deze fout treedt op wanneer Chrome niet goed opstart in de headless-modus, meestal als gevolg van een onjuiste configuratie of een gebrek aan systeembronnen. Geheugenopties aanpassen zoals lost het vaak op.
3. Waarom is het matchen van Chrome- en ChromeDriver-versies belangrijk?
4. Overeenkomende versies voorkomen compatibiliteitsfouten. Gebruiken en het ophalen van de specifieke ChromeDriver zorgt ervoor dat ze soepel samenwerken.
5. Hoe werkt hulp bij headless testen?
6. Hiermee kan een poort voor Chrome worden beheerd door ChromeDriver, waardoor tests effectiever verbinding kunnen maken met de browserinstantie en DevTools-fouten worden voorkomen.
7. Wat doet Doen?
8. Hierdoor wordt de sandboxing van Chrome uitgeschakeld, waardoor Chrome kan starten in CI-omgevingen, omdat sandboxing er soms voor kan zorgen dat Chrome zonder hoofd crasht in beperkte omgevingen.
9. Is er een terugval als de ChromeDriver-versie niet kan worden gedownload?
10. Ja, ons script bevat een fallback die gebruikmaakt van als de overeenkomende versie mislukt, zorg er dan voor dat ChromeDriver beschikbaar is, ongeacht de geïnstalleerde Chrome-versie.
11. Hoe voorkom ik Chrome-geheugengerelateerde problemen in CI/CD-pijplijnen?
12. Gebruiken leidt het gedeelde geheugen om, waardoor Chrome crasht vanwege de beperkte /dev/shm-ruimte in CI-omgevingen.
13. Kan ik fouten in Chrome opsporen in de headless-modus?
14. Ja, gebruiken en door lokaal een test uit te voeren, kunt u Chrome DevTools openen voor foutopsporing in de headless-modus.
15. Verwerkt WebDriverManager ChromeDriver-updates automatisch?
16. WebDriverManager vereenvoudigt stuurprogramma-updates lokaal, maar in CI/CD-pijplijnen is het instellen van specifieke versies, zoals weergegeven, betrouwbaarder voor herhaalbare builds.
17. Wat is het doel van in het script?
18. Met deze opdracht worden bronnen vrijgemaakt door Chrome te sluiten en de WebDriver-sessie te beëindigen, waardoor geheugenlekken in CI/CD-omgevingen worden voorkomen.
19. Hoe test ik mijn Selenium-installatie op GitHub Actions voordat ik een commit maak?
20. Lokaal testen uitvoeren met Opties en CI-configuraties kunnen problemen onderkennen voordat ze naar GitHub worden gepusht, waardoor het opsporen van fouten eenvoudiger wordt.
21. Welke rechten heb ik nodig voor ChromeDriver in CI?
22. ChromeDriver vereist uitvoeringsrechten, ingesteld door , om tests met succes uit te voeren in GitHub Actions.

Het garanderen van de juiste configuratie voor Selenium-tests met headless Chrome op GitHub Actions bespaart tijd en verhoogt de betrouwbaarheid. Het aanpakken van fouten zoals “DevToolsActivePort-bestand bestaat niet” kan CI/CD-tests naadlooser en minder frustrerend maken voor ontwikkelaars.

Door uit te lijnen en Chrome-versies en het configureren van geheugenefficiënte opties, helpt deze aanpak om tests efficiënt uit te voeren in beperkte omgevingen. Het is een praktische oplossing waarmee ontwikkelaars zich kunnen concentreren op hun kerntaken zonder zich zorgen te hoeven maken over testverstoringen 🚀.