Getting started
IntroductionInstalled packagesEnvironment variablesDebugging buildsCachingParallel testingDeployment pipelinesRunning commands as rootIgnoring commandsRun a command in case of an errorSetting timezoneAccess to other repositoriesUsing scriptsGit LFSUbuntu 20.04 Focal
IntroductionFTP/SSH/SFTP/RSYNCCustom scriptHerokuHeroku MigrationAWS Elastic BeanstalkAWS CodeDeployAWS LambdaAWS S3Google App EngineAWS CLIgcloud CLIAzure CLIDigital OceanEngine YardCapistranoGit PushCloudFoundryCloud66anynines
IntroductionBrowser testingBackground commandsGit submodulesCustom DNSArtifacts
IntroductionCassandraCouchDBDynamoDBMongoDBMySQLPostgreSQLSQLite
IntroductionDartElixirGoJava and JVMMeteorNode.jsPHPPythonRubyRust
IntroductionBeanstalkdRabbitMQRedis
IntroductionElasticsearchMemcachedSphinx
IntroductionCloudBees CodeShip Pro introduction guideCloudBees CodeShip Pro introduction guide 2CloudBees CodeShip Pro introduction guide 3CloudBees CodeShip Pro introduction guide 4CloudBees CodeShip Pro introduction guide 5
Migrating to CloudBees CodeShip Pro
Docker for CI/CD
Getting started with CloudBees CodeShip Pro overview and resources
IntroductionServices configSteps configEnvironment variablesImage registriesImage cachingBuild argumentsVolumesHandling secretsMultiple reposServices and databasesSetting an SSH private keyPreinstalled images
IntroductionInstallationUsing the Jet CLIjet cleanupjet decryptjet encryptjet generatejet loadjet runjet stepsjet updatejet validatejet version
IntroductionAWSAWS S3AWS EBAWS ECSAWS EKSAWS CodeDeployAzure Container ServiceHerokuGoogle CloudGoogle App EngineGoogle Cloud FunctionsGoogle Container EngineGoogle Compute EngineKubernetesTerraformDeploy Via SSHDocker SwarmIBM Cloud FoundryIBM Cloud Container Service
IntroductionBrowser testingParallel testing
IntroductionElixirGoJava and JVMNode.jsPHPPythonRuby
IntroductionCaching multi-stage DockerfileContainer is slow to exitDiffering results with Jet CLIDocker Hub rate limitingManaging multiple environments for a serviceReducing log output from dependent containersStep log not appearingUsing env vars in command steps

Browser testing

4 minute read

This article is about running browser testing in your CI/CD pipeline with CloudBees CodeShip Basic.

If you’d like to learn more about CloudBees CodeShip Basic, we recommend the getting started guide or the features overview page.

Chrome

Google Chrome is installed by default and is at version 129. It is located at /usr/bin/google-chrome.

There are chrome and Chrome symlinks in the PATH that default to calling Google Chrome.

You can check the exact version with chrome --version.

Chrome Beta

Sometimes it may be helpful to run your tests with the latest Chrome Beta version.

To install the current beta version add the following command to your build steps:

\curl -sSL https://raw.githubusercontent.com/codeship/scripts/master/packages/chrome-beta.sh | bash -s
▼

This script removes the pre-installed stable version of Chrome and replaces it with the current beta version.

Headless Chrome

Beginning in Google Chrome 59, you can run Chrome in headless mode. To take advantage of this be sure your build is targeting Google Chrome and using ChromeDriver 2.30 or greater. Your application will also need to pass the --headless flag to Chrome.

Additionally, you may need to pass the following option flags: --no-sandbox and --disable-gpu.

ChromeDriver

ChromeDriver 129.0.6668.89 is installed by default and available in the PATH.

You can check the exact version with chromedriver --version.

To install a custom ChromeDriver version add the following commands to your build steps:

export CHROMEDRIVER_VERSION=YOUR_DESIRED_VERSION

\curl -sSL https://raw.githubusercontent.com/codeship/scripts/master/packages/chromedriver.sh | bash -s
▼

Current available versions are on the Chrome for Testing availability dashboard.

Firefox

Firefox 122.0.1 is installed by default and available in the PATH.

To install a custom Firefox version add the following commands to your build steps:

export FIREFOX_VERSION=YOUR_DESIRED_VERSION

\curl -sSL https://raw.githubusercontent.com/codeship/scripts/master/packages/firefox.sh | bash -s
▼

Headless Firefox

Beginning in Firefox 55, you can run Firefox in headless mode. To take advantage of this be sure your build is targeting Firefox and using a current geckodriver version. Your application will also need to pass the -headless flag to Firefox.

geckodriver

geckodriver 0.35.0 is installed by default and available in the PATH.

To install a custom geckodriver version add the following commands to your build steps:

export GECKODRIVER_VERSION=YOUR_DESIRED_VERSION

\curl -sSL https://raw.githubusercontent.com/codeship/scripts/master/packages/geckodriver.sh | bash -s
▼

Selenium

Chrome and Firefox both work with Selenium. To support Selenium with Chrome be sure to update ChromeDriver to the desired version for your application. Please provide your own Selenium driver in your application and keep it current.

Selenium has additional notes on headless mode.

For Chrome, you may need to pass the following option flags: --no-sandbox and --disable-gpu.

Selenium Standalone Server

If there are no packages available for your framework or you want to use the standalone version there is a script available for installing a custom version.

Sauce Labs

You can use Sauce Connect to connect the Sauce Labs browser testing service with the application running in your CodeShip build.

There is a script available for installing Sauce Connect in the build environment. Make sure you set the username and API key or other necessary variables in the environment configuration. You can run your tests exactly the same way as you would run them on your own development machine through Sauce Connect.

PhantomJS

PhantomJS 2.1.1 is installed by default and available in the PATH.

To install a custom PhantomJS version add the following commands to your build steps:

export PHANTOMJS_VERSION=YOUR_DESIRED_VERSION

\curl -sSL https://raw.githubusercontent.com/codeship/scripts/master/packages/phantomjs.sh | bash -s
▼

Screenshots

During your tests you may want to generate screenshots when tests fail. CloudBees CodeShip Basic starts a new build machine for each build and that machine gets terminated as soon as the build finishes. As a result there is not a simple way to save screenshots from failing builds.

However, you can use a SSH debug session to manually run your failing build again which will generate new screenshots. Then from another terminal window you can use scp to copy any screenshot files from the debug machine to your local machine for viewing.

Here is an example command. Note that the PORT and IP_ADDRESS are the same as what you use to connect to the debug session and the file path will depend on where your tests place the screenshots.

scp -P PORT rof@IP_ADDRESS:/home/rof/clone/screenshots/my_screenshot.png .

Viewing browser tests with VNC

If your tests are running full versions of Chrome or Firefox, rather than running them in headless mode, you may want to try debugging tests by watching them run live with VNC.

To begin, start a SSH debug session.

Then connect to the debug session, taking note to forward port 5900:

ssh rof@IP_ADDRESS -p PORT -L 5900:localhost:5900

Now in the debug session run the following commands which will install TigerVNC and start the VNC server:

# Install TigerVNC
\curl -sSL https://raw.githubusercontent.com/codeship/scripts/master/packages/tigervnc.sh | bash -s

# Set a password for the VNC session
vncpasswd

Password:
Verify:
Would you like to enter a view-only password (y/n)? n

# Start the VNC server which will export the Xvfb display server that is already running
x0vncserver -display :99 -PasswordFile=$HOME/.vnc/passwd

Now your VNC server should be running and ready for connections. You can connect from your local machine with your VNC client of choice. If you are using macOS, you can connect with the built in VNC client called Screen Sharing.

From your VNC client, connect to localhost:5900 and enter the password you set in the step above. It should connect and show you a blank, black screen. This is expected as there are no browser tests running yet.

Now in a separate terminal window, connect back to the debug session and begin running your test commands manually. Once you start running your browser tests you should see them appear in the VNC display.

Introduction
Background commands