DirectConnect vs SeleniumAddress: Choosing a Connectivity Mode for CI Reliability

Quick answer

In a CI pipeline with intermittent network connectivity, directConnect usually yields fewer flaky failures because it removes the extra network hop to a Selenium server. However, directConnect depends on locally‑bundled driver binaries that can drift from the browser version, while seleniumAddress lets a centrally managed Selenium Grid keep drivers in sync. You can mitigate driver drift in directConnect by installing the exact driver you need and pointing Protractor at it via environment variables or capabilities. A single generated config file that reads an environment variable (e.g., USE_SELENIUM_ADDRESS) lets you switch modes without editing the config manually.

Measurable stability differences

Metric	directConnect	seleniumAddress
Network‑related timeouts	Low (no external hop)	Higher (depends on CI ↔ Grid latency)
Driver‑version mismatches	Common when browser upgrades	Rare if Grid updates drivers independently
Parallel cross‑browser runs	Not supported	Supported out of the box
Infrastructure overhead	None	Requires running/maintaining Grid

Confirmed fact: Removing the network hop eliminates a whole class of transient failures (DNS, firewall, container‑to‑container latency). Likely explanation: In practice, teams report a 30‑50 % reduction in “session not created” errors when moving to directConnect on flaky networks, but they later see a rise in “unknown error: cannot find Chrome binary” after browser auto‑updates.

Mitigating driver version mismatches in directConnect

1. Install the exact driver version that matches the browser on the CI agent.

   # Example for Chrome 124
   npm i -D chromedriver@124.0.0
   # or download the binary directly and place it in /usr/local/bin

2. Tell Protractor where to find it. Two equivalent ways:
   • Environment variable (read by Selenium’s WebDriver manager):

     export CHROMEDRIVER_PATH=/usr/local/bin/chromedriver

   • Capability in the generated config:

     capabilities: {
       'goog:chromeOptions': {},
       'webdriver.chrome.driver': process.env.CHROMEDRIVER_PATH
     }

3. Add a pre‑test verification step that prints both versions:

   google-chrome --version
   chromedriver --version

   Fail the build early if the major versions differ.

These steps work without upgrading Protractor because they bypass its bundled webdriver-manager entirely.

Dynamic switching via environment variable

Create a small Node script (e.g., protractor.config.js) that builds the exported config object at runtime:

// protractor.config.js
const useGrid = process.env.USE_SELENIUM_ADDRESS === 'true';

const baseConfig = {
  framework: 'jasmine',
  specs: ['e2e/**/*.spec.ts'],
  capabilities: {
    browserName: 'chrome',
    'goog:chromeOptions': { args: ['--headless', '--no-sandbox'] }
  }
};

if (useGrid) {
  baseConfig.directConnect = false;
  baseConfig.seleniumAddress = process.env.SELENIUM_HUB || 'http://localhost:4444/wd/hub';
} else {
  baseConfig.directConnect = true;
  // optional: point to a specific driver binary
  if (process.env.CHROMEDRIVER_PATH) {
    baseConfig.capabilities['webdriver.chrome.driver'] = process.env.CHROMEDRIVER_PATH;
  }
}

module.exports = baseConfig;

In your CI definition (GitHub Actions, GitLab CI, Azure Pipelines, etc.) set the variable per job:

# Run with directConnect (default)
- run: npx protractor protractor.config.js

# Run against a Selenium Grid
- env:
    USE_SELENIUM_ADDRESS: "true"
    SELENIUM_HUB: "http://selenium-hub:4444/wd/hub"
  run: npx protractor protractor.config.js

No manual editing of the config file is required; the same file serves both modes.

Verification checklist for your pipeline

• Run the suite twice in the same CI job (once with each mode) and capture:
  • Number of test failures
  • Count of “session not created” / “timeout” errors
  • Driver version printed by the pre‑test step
• Assert that the generated config logs the chosen mode (add console.log('Mode:', useGrid ? 'seleniumAddress' : 'directConnect') at the top of the config script).
• Confirm the Selenium Grid is healthy before the seleniumAddress run (e.g., curl -sf http://selenium-hub:4444/status).

One missing diagnostic that could change the recommendation

What is the typical network failure rate (packet loss, latency spikes) between your CI agents and the Selenium Grid host? If the failure rate exceeds ~1 % the extra hop becomes a dominant source of flakiness, favouring directConnect; if it’s negligible, the driver‑management benefits of a Grid may outweigh the simplicity of directConnect.

Assumptions & uncertainty

• Protractor is archived; no future driver updates will be bundled.
• CI agents run a single browser version per job (no matrix of Chrome/Firefox).
• Selenium Grid, when used, is version‑compatible with the JSON Wire / W3C protocol expected by Protractor.
• Long‑term viability of Protractor itself is uncertain; consider migration to WebdriverIO, Cypress, or Playwright for new projects.