skip to content

In Selenium 4, how would you decide between Selenium Manager resolving a driver per CI job and a pinned driver baked into the image?

level: principalimportance: should knowfreq 38%

answer

  1. Something in the job is not frozen
  2. Who supplies the driver binary
  3. A lookup order, not a switch
  4. Service, then env var, then property
  5. SE_CHROMEDRIVER skips Selenium Manager

basics

~20 s

Decide by what the job must guarantee. Selenium Manager resolves and downloads a matching driver at run time, which is convenient but depends on the network. A driver baked into the image and pinned makes the job repeatable offline.

solid answer

~40 s

Since Selenium 4.6 the client runs Selenium Manager automatically when no driver location is configured: it detects the browser version, resolves a matching driver, downloads it if the cache lacks it, and returns the path. That is convenient, but it makes every run depend on the network and lets two runs weeks apart use different binaries. Baking a browser and its matching driver into the image and pointing the suite at that driver — through `SE_CHROMEDRIVER`, the `webdriver.chrome.driver` system property, or `usingDriverExecutable` on the service — freezes that input, so a red run means your application broke rather than the toolchain moved. I pin for gating suites on restricted runners, and let the Manager resolve where following the newest browser is the point.

code

java · 12 lines
java
ChromeDriverService service =
    new ChromeDriverService.Builder()
        .usingDriverExecutable(new File("/opt/drivers/chromedriver"))
        .usingAnyFreePort()
        .build();

ChromeOptions options = new ChromeOptions();
options.addArguments("--no-sandbox", "--disable-dev-shm-usage");

WebDriver driver = new ChromeDriver(service, options);
driver.get("https://irrigation.example.internal/schedule");
driver.quit();

go deeper

for a junior

Know that Selenium 4 can find a driver for you and that you no longer have to download chromedriver by hand. Be able to say that a driver still has to exist somewhere before a session can start.

for a middle

Explain the lookup order: the service executable, then the driver environment variable, then the system property, then Selenium Manager. Say what happens on a cache miss with no network.

for a senior

Show that you have diagnosed a session that failed at start-up rather than in a test, and can tell a driver-resolution failure apart from an application failure in a CI log.

for a principal

Own the policy across many pipelines: which suites are allowed to follow the newest browser, which must be frozen, how a pin gets bumped on purpose, and what you measure to know the choice still holds.

## The two postures, stated plainly A browser suite on a build agent needs three things before the first test runs: a **browser**, a **driver** binary that speaks WebDriver to it, and a client that can find that driver. The third is where the two postures diverge. **Selenium Manager** is a small executable shipped inside the Selenium client itself, and since Selenium 4.6 the client runs it automatically. When a session is about to start and no driver location has been configured, the Manager detects the installed browser's version, works out the matching driver, downloads it if the local cache does not already hold it, and hands back a path. Nothing in your code calls it. **A baked, pinned driver** is the opposite: the image the job runs in already contains a known browser build and the exact driver that matches it, and the suite is told where that driver lives. The Manager never runs, because it is never asked. ## How Selenium 4 actually chooses This is not a switch you flip; it is a lookup order. Selenium 4's `DriverFinder` asks four sources in turn and takes the first that yields a path: 1. the executable set on the service object, via `ChromeDriverService.Builder().usingDriverExecutable(File)`; 2. the driver **environment variable**, which is `SE_CHROMEDRIVER` for chromedriver; 3. the driver **system property**, `webdriver.chrome.driver`; 4. **Selenium Manager**, as the fallback when the first three are silent. That is the whole seam. Exporting `SE_CHROMEDRIVER` in the image takes the Manager out of the picture; unsetting it puts the Manager back. When one of the first three answers, the client logs that it is skipping Selenium Manager — the line to grep for when you are unsure which posture a job is really in. When the Manager runs and cannot resolve anything, the client raises `NoSuchDriverException` at session start. ## What each posture costs | Concern | Manager resolves per job | Driver baked and pinned | |---|---|---| | Where the driver comes from | the run-time cache, or a download | already inside the image | | Network needed at test time | yes, on a cache miss | no | | An upstream browser release | picked up on the next run | picked up when someone rebuilds | | Two runs a month apart | may use different binaries | use the same binaries | | Typical failure | `NoSuchDriverException` at session start | an image build that does not ship | | Who reviews the version change | nobody | whoever reviews the image change | ## The judgment, not the recipe The nightly suite for a farm irrigation-schedule panel is the case that makes this concrete. It runs unattended, it gates a deploy, and nobody watches it at 03:00. - **What must the job guarantee?** If a red run has to mean "the irrigation panel broke", every input other than your code should be frozen. A resolved-at-run-time driver is an unfrozen input. - **How locked down is the agent?** Egress-restricted or air-gapped runners turn the Manager's download into a hard dependency on a proxy allow-list. Baking removes the question. - **How fast do you want browser upgrades?** Managed resolution follows the browser automatically, which is genuinely useful on an exploratory or compatibility job where you *want* the newest build. Pinning deliberately delays that until a human bumps it. - **Who owns the failure?** A pinned image turns a browser upgrade into a reviewable change with an author. Automatic resolution turns it into a surprise on an unrelated pull request. - **What is the blast radius?** One flaky job can tolerate an occasional download; forty pipelines sharing one runner pool cannot all discover a new driver on the same morning. A workable middle ground exists and is worth naming: let the Manager run, but persist its cache between runs and pin the versions it is allowed to resolve. That keeps the ergonomics while removing most of the run-to-run variance. The detailed configuration surface for that — the cache location, the version overrides and offline mode — is the Manager's own subject; what matters here is that the middle ground is available and does not have to be all-or-nothing. ## What I would measure before and after 1. **Session-start failures** as a share of runs, separated from test failures. Driver resolution problems show up here and nowhere else. 2. **Job duration variance.** A download on a cache miss adds seconds to some runs and not others; if that spread is invisible, the Manager is not costing you anything yet. 3. **Version skew** between what the pipeline image ships and what engineers run locally. A wide gap is how "passes on my machine" becomes a weekly conversation. 4. **How often the pin moves.** A pinned driver nobody has bumped in a year is not stability, it is an unowned upgrade waiting to happen. The honest summary: pin when the job's job is to be trustworthy, resolve when the job's job is to tell you about the newest browser, and never let the choice be an accident of which environment variable happened to be set on the agent.

  • Your runners have no outbound internet. What breaks first, and what would you change?
    Selenium Manager cannot download a driver on a cache miss, so the very first session fails with `NoSuchDriverException` before any test runs. Either bake the driver into the image and set `SE_CHROMEDRIVER`, or give the Manager a reachable mirror and a cache that survives between jobs. Baking is the smaller moving part on a restricted runner.
  • How would you stop a pinned driver from silently rotting for a year?
    Make the pin a dependency like any other: a scheduled job that rebuilds the image against the newest browser and runs the suite, opening a change when it passes. That way the upgrade is a reviewed diff with an author, on a cadence you chose, rather than a surprise the day someone rebuilds for an unrelated reason.
  • Is there a posture between the two?
    Yes. Let Selenium Manager run, but persist its cache between jobs and constrain which versions it may resolve. You keep the ergonomics of automatic resolution while removing most run-to-run variance and most of the network dependence. It is a reasonable default for non-gating suites that still need to be broadly reproducible.

It is the difference between shopping for ingredients on the way to the kitchen and stocking the pantry in advance: one is flexible until the shop is shut, the other is boring and always works.

saying these in an interview costs you the question

  • Thinks Selenium Manager needs an explicit call in test code
  • Assumes Selenium Manager works offline because something is cached
  • Believes pinning the browser image alone pins the driver too
  • Treats automatic driver resolution as free reproducibility
  • Cannot say which source Selenium checks before the Manager