Skip to content

[🐛 Bug]: 9.19.0 automatic xvfb breaks existing CI workflows and cannot be disabled #14698

@jesse-r-s-hines

Description

@jesse-r-s-hines

Have you read the Contributing Guidelines on issues?

WebdriverIO Version

1.19.0

Node.js Version

18

Mode

WDIO Testrunner

Which capabilities are you using?

What happened?

The recent addition of automatic Xvfb-run on headless systems looks great! But it currently can break existing CI workflows that already used xvfb, or workflows that need more advanced display server setup, as it always creates a new xvfb-run session on a different DISPLAY port. E.g. in one of my projects I have xvfb set up with herbstluftwm as a window manager, but it is no longer working as wdio is making its own xvfb session.

Currently there seems to be no way to stop the automatic xvfb-run in a CI environemnt, as the shouldRun method always returns true if it detects CI. The autoXvfb config sounds like it should turn of this behavior, but appears to only disable the automatic install of xvfb, not the usage of xvfb-run if it's present.

What is your expected behavior?

Can you either make autoXvfb: false disable the xvfb-run behavior entirely or add a new config parameter to do so for these kinds of use cases?

How to reproduce the bug.

E.g. a CI workflow with something like this:

export DISPLAY=:99
Xvfb $DISPLAY -screen 0 1280x1024x24 +extension GLX -noreset &
sleep 1
herbstluftwm &
sleep 1
npx wdio run ./wdio.conf.ts

will now no longer use the created DISPLAY and window manger.

Relevant log output

N/A

Code of Conduct

  • I agree to follow this project's Code of Conduct

Is there an existing issue for this?

  • I have searched the existing issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions