CI/CD

Introduction

What is the CI/CD screen?

The CI/CD Integration screen (reached at the /cicd route) is a generator. You pick the CI/CD service you use, confirm a few options about how your tests should run, and Testver writes out the exact pipeline configuration file that service expects — a .github/workflows/tests.yml, a .gitlab-ci.yml, a Jenkinsfile, and so on. The file appears in an editable preview on the right; you can tweak it, copy it, or save it straight into your project.

CI/CD stands for Continuous Integration / Continuous Delivery. In plain English: every time you (or a teammate) push code or open a pull request, a server automatically checks out your project, installs its dependencies, and runs your test suite — without anyone having to remember to do it by hand. If a test fails, the team finds out within minutes instead of after a release ships.

The catch is that every CI/CD service speaks its own dialect. GitHub Actions wants YAML in a very particular folder; Jenkins wants a Groovy Jenkinsfile; CircleCI wants .circleci/config.yml. Writing those by hand is fiddly and easy to get wrong. This screen does the translating for you.

Tip

Analogy: think of this screen as a travel-adapter shop. Your test suite is the appliance; each CI/CD provider is a country with a different wall socket. You tell the shop which appliance you have (your framework) and which country you’re flying to (your provider), and it hands you the exact adapter — already shaped to plug in.

Note

In one sentence: the CI/CD screen converts “I want to run my tests on every push” into the precise config file your CI/CD provider needs, and drops it into your repo.

Who this guide is for

This guide is written for anyone who wants their Testver-managed test suite to run automatically in a CI/CD pipeline, regardless of how much pipeline experience they have:

• Testers and QA engineers who know their tests but have never hand-written a pipeline YAML file and don’t want to start now.
• Developers who already have a CI/CD provider and just need a correct, framework-aware starting config they can commit and refine.
• Team leads standardizing how tests run across repositories — same triggers, same artifact retention, same timeout everywhere.
• Anyone migrating providers (e.g. GitLab to GitHub) who wants the equivalent config regenerated rather than rewritten from scratch. No prior knowledge of YAML, Groovy, or pipeline syntax is assumed. You will, however, get more out of the screen if you know which CI/CD provider your repository is hosted on and which test framework your project uses.

Key terms

These terms appear throughout this screen and the generated files. Skim them once and the rest of the guide reads easily.

Term	Plain-English meaning
Pipeline	The automated sequence of steps a CI/CD service runs for you — typically: check out code, install dependencies, run tests, collect results. The config file this screen generates is the definition of that pipeline.
Runner / agent	The machine (usually a fresh, throwaway virtual machine in the cloud) where the pipeline actually executes. GitHub calls it a runner; Jenkins calls it an agent. You choose what software it has (e.g. a Node.js version) through the options on this screen.
Artifact	A file the pipeline produces and keeps after it finishes — a test report, screenshots, a trace. The Upload Artifacts toggle controls whether your results are saved, and Artifact Retention controls for how many days.
Trigger	The event that starts the pipeline. This screen supports four: push (code pushed), pull_request (a PR opened or updated), schedule (a recurring time, set by cron), and manual (a human clicks Run).
Secret	A sensitive value — API key, password, token — stored securely by your CI/CD provider rather than written into the config file. The generated file references secrets by name; you add the actual values in your provider’s settings, never in the YAML.
Cron	A five-field text pattern that describes a repeating schedule, e.g. 0 6 * * * = every day at 06:00 UTC. Only relevant when the schedule trigger is enabled.
Sharding (parallel)	Splitting one test run across several machines at once so it finishes faster. Supported for frameworks that handle it natively (Playwright, Cypress).

How it works

Under the hood the screen runs a small, predictable loop. Understanding it explains why the preview behaves the way it does.

1. Scan. When the screen opens, Testver scans your project to detect (a) which test framework you use and (b) any CI/CD config files that already exist on disk. The detected framework appears as a small pill next to the page title.
2. Select. You pick a provider card. The first time you select a provider with no existing file, Testver generates a fresh config from your current options.
3. Generate or patch. Whenever you change an option, Testver reacts after a short pause (about 300 ms of debounce). For a brand-new file it re-generates the whole config; for a file already on disk it applies a surgical patch so your manual edits survive.
4. Preview & edit. The result lands in a Monaco code editor on the right. It is fully editable — anything you type becomes part of what gets saved.
5. Save. Clicking Save to Project writes the file to its standard path in your repository. From there you commit it like any other file, and your CI/CD provider picks it up on the next push.

Note

Testver generates the file and writes it into your repo. It does not run the pipeline for you — the actual execution happens on your CI/CD provider once you commit the file. There is no Testver-hosted runner and no run-status reported back into this screen.

Getting Started

Opening CI/CD

1. Make sure a project is open in Testver — the CI/CD screen always works in the context of the currently-open project (it reads that project’s framework and scans that project’s folders).
2. Navigate to the CI/CD screen from the main navigation (route /cicd). The page title reads CI/CD Integration.
3. Wait a moment for the initial scan. If Testver recognizes your test framework, a small colored pill (e.g. playwright) appears just after the subtitle.
4. If you already have pipeline files, an Existing CI/CD Configurations list appears at the top of the left panel showing what was found.
5. Pick a platform card under Generate New Config to begin.

Tip

If the framework pill is missing or wrong, don’t worry — you can override it explicitly with the Test Framework dropdown once you’ve selected a platform. Detection is a convenience, not a requirement.

The screen layout

The screen is a header bar over a two-pane workspace. A draggable divider sits between the panes.

Area	Location	What it does
Page header	Top, full width	Shows the CI/CD Integration title, the subtitle, and the detected-framework pill. Holds the Re-scan button on the right.
Re-scan button	Top-right of header	Re-runs detection of existing config files and the project framework. Use it after you add or delete pipeline files outside Testver.
Existing CI/CD Configurations	Top of left pane (only if files were found)	Lists each detected pipeline file with its name, provider, and path. Hovering a row reveals a jump button.
Generate New Config	Left pane	Heading over the grid of platform cards — your starting point for creating a config.
Platform cards	Left pane, two-column grid	One card per supported provider. Click to select; selected card is highlighted, and providers you already have a file for show a green check.
Configuration Options	Left pane, below the cards (appears after you select a platform)	The form that shapes the generated file: framework, runtime version, triggers, branches, toggles, env vars, and more.
Draggable divider	Between the two panes	A thin vertical bar; grab and drag it to widen either pane. Your width preference is remembered between sessions.
Preview pane	Right pane (the larger side)	Shows the generated file in an editable code editor with a toolbar (Reset, Copy, Save) and a modified-status chip. Before you pick a platform it shows a “Select a Platform” placeholder.

At a glance

• Six providers are supported: GitHub Actions, GitLab CI, Jenkins, Azure Pipelines, Bitbucket Pipelines, and CircleCI.
• Every option on the form is honored by every provider — there is no “this only works on GitHub” gotcha.
• The preview is a real editor: edit freely, and your edits are what gets saved.
• Changes to options auto-apply after a short pause — no “Generate” button to press.
• Saving writes to the provider’s standard path; an overwrite confirmation protects any existing file.
• Switching platforms with unsaved edits prompts you to Save & Switch or Discard & Switch.

Choosing a Provider & Options

Selecting a CI/CD provider

Under Generate New Config, the cards represent the six supported CI/CD providers. Each card shows an icon, the provider name, and a one-line description. A green check badge in the top-right corner means Testver already detected a config for that provider in your project. Click a card to select it (the selected card gets a highlighted border); the Configuration Options form then appears below, and a preview is generated on the right.

Provider	Generated file	Where it lives in your repo
GitHub Actions — Automate workflows directly in your GitHub repository	tests.yml	.github/workflows/tests.yml
GitLab CI — Built-in CI/CD for GitLab repositories	.gitlab-ci.yml	.gitlab-ci.yml (repo root)
Jenkins — Open-source automation server with pipeline support	Jenkinsfile	Jenkinsfile (repo root)
Azure Pipelines — CI/CD service for Azure DevOps	azure-pipelines.yml	azure-pipelines.yml (repo root)
Bitbucket Pipelines — Integrated CI/CD for Bitbucket Cloud	bitbucket-pipelines.yml	bitbucket-pipelines.yml (repo root)
CircleCI — Continuous integration and delivery platform	config.yml	.circleci/config.yml

Tip

Pick the provider that matches where your repository is hosted. If your code is on GitHub, GitHub Actions needs no extra setup; on GitLab, GitLab CI is built in; CircleCI and Jenkins are standalone services you connect to your repo separately.

Configuration Options

The Configuration Options form is where you tune the pipeline. Every field below feeds the generator, and (with the noted exceptions) every field is honored by all six providers. Fields appear conditionally depending on your framework and toggles.

Option	Effect on the generated config
Test Framework	Overrides the auto-detected framework. Choosing one changes the install/run commands the pipeline uses and which runtime-version picker is shown. If your pick differs from what was detected, an amber “Overriding detected framework” note appears. Options span Node.js (Playwright, Cypress, Jest, Vitest, Mocha, WebdriverIO, Puppeteer, Cucumber, Generic), Python (pytest, Robot Framework), Java (Maven, Gradle, TestNG), .NET (dotnet test, NUnit, xUnit), and Ruby (RSpec).
Node.js Version	Shown for Node.js frameworks. Sets which Node version the runner installs (18 LTS, 20 LTS, or 22). Default 20.
Python Version	Shown for Python frameworks (pytest, Robot). Choices 3.10, 3.11, 3.12. Default 3.11.
Java Version	Shown for JVM frameworks (Maven, Gradle, TestNG). Choices 11, 17, 21. Default 17.
.NET Version	Shown for .NET frameworks (dotnet, NUnit, xUnit). Choices 6.0, 7.0, 8.0. Default 8.0.
Timeout (min)	The maximum minutes the job may run before the provider cancels it. Range 5–120, default 30. Honored by every provider.
Triggers	Toggle buttons for push, pull request, schedule, and manual. These set which events start the pipeline. Default has push and pull request on.
Branches	Comma-separated list of branch names the push/pull_request triggers apply to (e.g. main, develop). Default main.
Cron Schedule	Appears only when the schedule trigger is on. A standard 5-field cron pattern, default 0 6 * * * (daily at 06:00 UTC).
Upload Artifacts	When on (default), the pipeline saves test outputs (reports, screenshots, traces) as downloadable artifacts. Honored by every provider.
Artifact Retention (days)	Appears only when Upload Artifacts is on. How long the provider keeps the artifacts. Range 1–90, default 30.
Parallel (Shard)	Appears only for shardable frameworks (Playwright, Cypress). Splits the test run across multiple machines to finish faster.
Shard Count	Appears only when Parallel is on. Number of parallel shards, range 2–10, default 4.
Use Docker agent	Appears only when the Jenkins platform is selected. Runs the Jenkins pipeline inside a Docker container agent rather than directly on the host.
Environment Variables	A key/value editor (Add / trash-icon to remove). Each pair is injected into the pipeline’s environment. Use this for non-secret config; store secrets in your provider’s secret store and reference them instead.

Caution

Do not type real secrets (passwords, API keys, tokens) into the Environment Variables editor — those values land in plain text inside a file you commit to your repository. Instead add them as secrets in your CI/CD provider’s settings and reference them by name in the YAML.

Note

The runtime-version picker is mutually exclusive: only the picker matching your selected framework’s runtime is shown (Node.js, Python, Java, or .NET). Switching the Test Framework swaps which picker appears.

Generating, Previewing & Using the Config

Automatic generation

There is no “Generate” button — generation is automatic. The moment you select a platform, Testver produces a first config. Every subsequent change to an option re-runs the generator (or patches the existing file) after roughly a 300 ms pause, so rapid edits coalesce into a single update rather than firing on every keystroke.

1. Select a platform card. A config is generated immediately and appears in the right pane.
2. Adjust any Configuration Options — the preview updates a moment after you stop changing things.
3. If a generation fails for any reason, Testver shows an error toast explaining why; the previous preview stays put rather than blanking out.

Note

If the platform you select already has a file on disk, Testver loads that file’s actual content into the editor and parses its settings back into the options form, so what you see reflects your real file — not library defaults. In that mode, option changes are applied as in-place patches that preserve your manual edits.

The preview editor

The right pane is a full Monaco code editor (the same editor engine as VS Code). It is syntax-highlighted — YAML for .yml/.yaml files, Groovy for a Jenkinsfile — with line numbers, word wrap, and no minimap. It is not read-only: you can click in and edit the generated config directly, and your edits are what gets saved.

The preview toolbar shows the file name and its target path. A modified-status chip appears when your editor content differs from the baseline:

Chip / state	Meaning
No chip	The editor matches the baseline — nothing to reset or save beyond what was generated.
Modified (amber)	You’ve edited a freshly-generated config; it now differs from the generated default.
File modified (amber)	You’ve edited a config that was loaded from a file on disk; it now differs from the saved file.

Preview toolbar actions

Three actions sit in the top-right of the preview toolbar (Reset appears only when there are changes to revert):

Button	What it does
Reset to file / Set to defaults	Reverts the editor to its baseline. If the config came from a file on disk, the label is Reset to file and it restores the on-disk content. If the config was freshly generated, the label is Set to defaults and it regenerates from your current options, discarding manual edits but keeping your selected options. Only visible when the config is modified.
Copy	Copies the entire current editor content to your clipboard. The button briefly shows Copied to confirm. Use this if you’d rather paste the config somewhere yourself instead of saving it through Testver.
Save to Project	Writes the current editor content to the provider’s standard path in your project. Briefly shows Saving… then Saved! on success. After saving, the existing-configs list refreshes.

Saving the config

Saving writes to the standard path for the selected provider (the paths listed in the table in section 3.1 — e.g. .github/workflows/tests.yml for GitHub Actions). You don’t choose the location; the provider dictates it.

If a file already exists at that path, Save to Project does not silently overwrite it. Instead an Overwrite existing config? confirmation dialog appears, warning that saving replaces the current content and cannot be undone. Choose Overwrite to proceed or cancel to keep the existing file. Commit any manual edits to source control first so you can recover them if needed.

Caution

Saving overwrites the target file in place and the action cannot be undone from within Testver. If the file is already tracked in Git, commit (or at least stage) your current version before overwriting, so the previous content is recoverable.

Existing CI/CD configurations

The Existing CI/CD Configurations panel at the top of the left pane lists every pipeline file Testver detected, each showing its file name, provider, and path. Hovering a row reveals a jump button that selects that file’s platform and loads it for editing. Use Re-scan in the header to refresh this list after changing files outside Testver.

If you click a different platform card while the editor has unsaved changes, Testver pauses and shows an Unsaved changes dialog with two choices: Save & Switch (persists your current config, then switches — if the save fails you stay put with edits intact) or Discard & Switch (drops the edits and switches immediately).

Triggers and start conditions

The pipeline’s start conditions are defined entirely by the Triggers you choose: push, pull_request, schedule (with a cron pattern), and manual. These are written into the config so your CI/CD provider knows when to run.

Note

Webhook wiring and run reporting happen on your provider’s side, not in Testver. GitHub Actions, GitLab CI, and the others watch your repository natively once the config file is committed — no separate webhook setup is needed for the built-in triggers. Test results and pass/fail status appear in your provider’s own UI (and, if Upload Artifacts is on, as downloadable artifacts there). Testver does not receive run status back from the pipeline; this screen is a generator, not a dashboard.

Common Tasks (How Do I…?)

I want to…	Do this
Generate a GitHub Actions pipeline	Select the GitHub Actions card. The tests.yml config appears in the preview; click Save to Project to write it to .github/workflows/tests.yml.
Run tests on a schedule (e.g. nightly)	In Triggers, enable schedule. A Cron Schedule field appears — set it (e.g. 0 6 * * * for daily 06:00 UTC).
Run only on certain branches	Edit the Branches field with a comma-separated list, e.g. main, develop.
Use a specific Node/Python/Java/.NET version	Pick the framework in Test Framework, then choose the version in the matching runtime-version picker.
Override the auto-detected framework	Open the Test Framework dropdown and pick the correct one; an amber override note confirms the change.
Make tests run faster	For Playwright or Cypress, turn on Parallel (Shard) and set a Shard Count.
Keep test reports/screenshots longer	Ensure Upload Artifacts is on, then raise Artifact Retention (days).
Pass a config value to the pipeline	Use the Environment Variables editor (Add, then fill key and value). For secrets, reference them from your provider’s secret store instead.
Run the Jenkins pipeline in a container	Select Jenkins, then enable Use Docker agent.
Discard my manual edits but keep my option choices	Click Set to defaults (shown when the config is generated and modified).
Get back the exact file that’s on disk	Open that platform from Existing CI/CD Configurations, then click Reset to file.
Use the config without saving through Testver	Click Copy and paste it into your repository yourself.
Switch providers without losing edits	Click the new platform card; in the Unsaved changes dialog choose Save & Switch.
Refresh the list of detected configs	Click Re-scan in the header.
Make either pane bigger	Drag the vertical divider between the two panes; the width is remembered next time.

Tips & Best Practices

• Commit the file to version control. A pipeline config only takes effect once it’s committed to your repository — saving it locally through Testver is step one; git commit and git push are step two.
• Never put secrets in Environment Variables. Use your provider’s secret store and reference secrets by name. The committed config is plain text and visible to anyone with repo access.
• Confirm the framework before generating. A wrong framework means wrong install/run commands. Check the detected pill and override via Test Framework if needed.
• Match the runtime version to your project. Pick the same Node/Python/Java/.NET version your project actually targets, so CI mirrors local behavior.
• Keep Upload Artifacts on while stabilizing. Reports, screenshots, and traces are invaluable when a CI run fails and you can’t reproduce it locally.
• Start with the defaults. The default triggers (push + pull_request), 30-minute timeout, and 30-day retention are sensible for most teams — change them only when you have a reason.
• Use Re-scan after external changes. If you add or delete pipeline files outside Testver, click Re-scan so the detected-configs list and overwrite guard stay accurate.
• Treat the preview as a starting point. The generated config is correct and runnable, but real projects often need a custom build step or extra job — edit freely in the preview before saving.
• Prefer Reset over manual undo. If edits go sideways, Reset to file / Set to defaults gives you a clean baseline instead of hand-reverting.

Troubleshooting & FAQ

The preview pane is empty

You haven’t selected a platform yet, or a generation failed. Click a platform card under Generate New Config. If you selected one and still see nothing, check for an error toast — it explains why generation failed (e.g. a backend error).

The wrong framework was detected

Detection is best-effort. Select your platform, then use the Test Framework dropdown to set the correct framework explicitly. Your choice overrides detection and an amber note confirms it.

My option change didn’t update the preview

That’s expected. The preview waits about 300 ms after you stop changing options before regenerating, so it doesn’t rebuild on every keystroke. Pause briefly and the update appears.

My manual edits got overwritten

When the config is a freshly-generated one (chip reads Modified), changing options regenerates the whole file and can replace manual edits. When the config came from disk (chip reads File modified), option changes are patched in place and your edits survive. If you want to lock in manual edits, click Save to Project — once saved and re-opened from disk, future option changes patch rather than regenerate.

A file already exists at that path

If a file already exists at the target path, Testver asks before replacing it. Choose Overwrite to proceed. If you cancel, nothing is written. Commit the existing file to Git first if you want a way back.

I lost my edits when switching platforms

Switching platforms with unsaved changes shows an Unsaved changes dialog. Choose Save & Switch to keep them. Discard & Switch intentionally throws them away. If you picked Discard, the edits are gone — regenerate from options to rebuild.

Does Testver run my pipeline?

No. This screen only generates and saves the config file. Execution happens on your CI/CD provider after you commit the file. There is no Testver-hosted runner, and run status is not reported back into this screen — check your provider’s UI for results and artifacts.

Where do I put secrets?

In your CI/CD provider’s settings (GitHub repo Secrets, GitLab CI/CD Variables, Jenkins Credentials, etc.), then reference them by name in the YAML. Do not put them in the Environment Variables editor — that content is committed in plain text.

Can I generate configs for more than one provider?

Yes. Generate and save one provider’s file, then select another platform card and repeat. Providers you already have files for are marked with a green check on their card and listed under Existing CI/CD Configurations.

Related

• Runner — local equivalent.
• Schedules — Testver-driven recurring runs.
• Settings → Run Commands — defaults the generator references.
• Git — commit the config from Testver after generating.