Run Endtest After a Jenkins Build, Without Turning Your Pipeline Into a Guessing Game

If the build is still changing, browser tests become noise. The useful pattern is simple: build first, then run Endtest only after the artifact is stable, and fail the pipeline only when the Endtest result is actually relevant to release readiness.

This tutorial shows a Jenkins-first workflow for running Endtest after a build stage, using the official Jenkins integration. The goal is not to add “more tests”, it is to make post-build browser tests predictable, reportable, and easy to hand off to the rest of the pipeline.

Bottom line

If you already use Jenkins for build orchestration, the cleanest setup is to keep the build, test, and deployment concerns separate:

1. Build the artifact.
2. Deploy or expose that artifact in a stable test target.
3. Trigger Endtest from a later stage.
4. Wait for Endtest to finish.
5. Publish the result back into Jenkins.
6. Fail the pipeline only when Endtest reports failures or errors.

That is exactly the kind of flow the official Endtest Jenkins plugin is designed for. The plugin documentation says it can start Endtest executions from a Jenkins Pipeline, wait for results, use results in later steps, store credentials securely, and optionally fail the build when Endtest reports failures or errors.

The key design choice is timing. Do not trigger Endtest from the build stage itself if your app or artifact is still being mutated. Run it after the build is stable, or after the app is deployed to a testable environment.

What “after a Jenkins build” should mean

People often use that phrase to mean two different things:

• After compile/package only, which is useful when the test target is already deployed elsewhere.
• After deploy to a test environment, which is usually better for browser tests because Endtest can exercise the live artifact in a known URL.

For Endtest, the second interpretation is usually the safer one. End-to-end browser tests care about the deployed user flow, not just whether the build produced files successfully.

A good Jenkins workflow makes that distinction explicit.

Recommended stage order

If your team skips the deploy/test-target stage and runs browser tests against a moving local build, you can still make it work, but debugging becomes harder because failures may come from unfinished startup, port mismatch, or asset timing rather than the actual user flow.

How the Endtest Jenkins integration fits

The official Endtest Jenkins integration is the right starting point when you want Jenkins to orchestrate test execution without building a custom polling script from scratch.

According to the documentation, the plugin supports:

• Secure storage of Endtest API credentials in Jenkins
• Single Endtest executions
• Multiple executions started by the same API request
• Label-based Endtest API requests
• Automatic polling until result data is available
• Aggregate results across multiple executions
• Optional Jenkins build failure when Endtest reports failures or errors
• Resuming result polling after a Jenkins controller restart
• json and json-light result formats

That combination matters because a lot of CI trouble comes from the boring parts, not the test itself. Polling, retries, and result handling are where homegrown scripts often become fragile.

Setup sequence in Jenkins

The setup is straightforward, but each step is there for a reason.

1) Confirm the Jenkins version and permissions

Endtest documents a minimum of Jenkins 2.528.3 or newer, plus permission to install plugins and create credentials.

Before you start, make sure you have:

• A Jenkins instance that meets the version requirement
• Permission to install plugins
• Permission to create credentials
• An Endtest account
• Your Endtest App ID and App Code
• An Endtest API request that starts the suite, configuration, or label you want to run

2) Install the Endtest plugin

In Jenkins, open Manage Jenkins → Plugins → Available plugins, search for Endtest, install it, and restart Jenkins if prompted.

This is the preferred route if you want the integration to remain maintainable. It keeps the credential flow and result handling inside the Jenkins ecosystem instead of spreading it across ad hoc shell scripts.

3) Store Endtest credentials in Jenkins Credentials

Endtest recommends storing the App ID and App Code in Jenkins Credentials rather than hardcoding them in the Jenkinsfile.

That recommendation is worth following for two reasons:

• It keeps secrets out of source control
• It lets multiple jobs reuse the same credential entry

If you are managing pipelines for several environments or services, this is the difference between one secure credential mapping and a drift-prone collection of copy-pasted values.

4) Prepare the API request in Endtest

For test execution, Endtest documents a GET request returned by Get API Request in the Run Test Suite modal.

Use that generated request rather than reconstructing the URL by hand. Endtest’s API documentation says a web test execution starts with a GET request and supports documented execution parameters such as action=runWeb, appId, appCode, suite or label, and other supported execution options. If you need the exact request shape, copy it from the product UI and keep it intact.

Important distinction: any extra query parameters you add to the start request are treated as test variables, not new execution-control parameters. That matters if you want to pass environment-specific values into the test.

A practical Jenkinsfile structure

Below is a simple pipeline layout that shows where the Endtest stage belongs. It does not invent plugin-specific syntax, because the exact step name should come from the official plugin docs. Instead, it shows the pipeline shape you want to preserve.

# Conceptual pipeline shape, not a Jenkinsfile syntax example
stages:
  - build
  - deploy-test-target
  - endtest
  - gate

A more realistic Jenkins declarative pipeline would look like this structurally:

groovy pipeline { agent any

stages { stage(‘Build’) { steps { sh ‘mvn clean package’ } }

stage('Deploy test target') {
  steps {
    sh './deploy-to-test-env.sh'
  }
}

stage('Endtest') {
  steps {
    // Use the official Endtest Jenkins integration here.
    // Store App ID / App Code in Jenkins credentials.
    // Start the Endtest execution after the target is stable.
  }
}

stage('Gate') {
  steps {
    // Fail or continue based on Endtest result.
  }
}   } }

The important part is not the syntax in this article, it is the placement. Endtest belongs after the artifact exists and after the app is reachable in a stable environment.

How to handle failure cleanly

Failure handling is where teams either get useful gating or a noisy pipeline.

Endtest’s Jenkins integration can optionally fail the Jenkins build when Endtest reports failures or errors. That is the behavior you want for release gating, but only when the test is actually part of the acceptance path.

A good rule:

• Fail the build when Endtest is validating a candidate release or a production-like deployment
• Mark unstable or notify only when Endtest is exploratory, non-blocking, or run on a branch that should not stop delivery

If your Jenkins flow needs a softer policy, keep the Endtest stage but separate result consumption from pipeline failure. That lets you still publish the report and keep the execution history without blocking every developer branch.

Common failure modes to watch

These are the failures that usually matter in this setup:

• Build passed, app is not ready yet. Add a stable deploy or readiness step before Endtest.
• Wrong environment URL. Make the test target explicit and visible in the pipeline.
• Credentials stored in the Jenkinsfile. Move them into Jenkins Credentials.
• A test failure is treated like a build failure without context. Publish the Endtest result link and summary so the team can see what failed.
• Polling is interrupted by controller restart. The plugin documents resume support, which is useful if your Jenkins controller is not perfectly stable.

Report handoff: what to pass to the next stage

A browser test run is only useful if the next person can read the result without searching three systems.

The Endtest Jenkins integration documents support for:

• Waiting until executions finish
• Aggregate results across multiple executions
• Result formats such as json and json-light

That means your post-test stage can do more than just fail or pass. It can hand off useful context to downstream steps, such as notifications, release notes, or defect creation.

A practical handoff usually includes:

• Execution status
• Result link
• Test counts or summary data
• Environment name
• Build number or commit reference from Jenkins

If your team already has a Jira-driven defect flow, Endtest also provides a Jira integration page, but that is a separate workflow. For the Jenkins path, the main goal is to make the result visible in the pipeline run and easy to trace back to the artifact that was tested.

When a custom script is still worth it

The official plugin should be your first choice for Jenkins. Still, there are cases where a custom shell step is defensible:

• You need a very specific handoff to another internal system
• Your Jenkins setup has constraints that make plugin installation difficult
• You are prototyping and want to validate the Endtest API flow first

If you go that route, use the Endtest API carefully. The documented workflow is to start a run with the API request from Endtest, then fetch results with action=getResults, appId, appCode, hash, and format.

That said, a script has a maintenance cost:

• You own the polling loop
• You own retry behavior
• You own controller restart handling
• You own parsing and formatting the result
• You own the failure semantics

For a team that wants browser tests in CI without building another mini-platform, the plugin is the lower-risk option.

Where Endtest is the better fit

Choose Endtest if your main problem is not “how do I write browser automation?”, but “how do I run stable browser checks after Jenkins builds without adding another maintenance burden?”

It fits especially well when you want:

• A native Jenkins integration
• Secure credential storage in Jenkins
• Automatic polling and result aggregation
• Optional build failure on test failure
• Editable, platform-native test steps instead of maintaining a large custom framework

Because Endtest uses low-code and agentic AI workflows, it can reduce the amount of framework code your team has to own. That does not make it universal, but it does make it attractive for teams that want readable, maintainable test logic rather than a large codebase of automation plumbing.

When a different tool may be better

A serious alternative is still the better choice in some situations.

• Cypress, if your team wants source-code-first browser tests tightly owned by developers and already has the discipline to maintain that codebase.
• Appium, if the problem is primarily mobile automation rather than post-build browser validation.
• BrowserStack or Applitools, if your main need is a cloud test grid or visual validation layered onto another automation stack.
• ACCELQ or Autify, if you are evaluating other codeless or AI-assisted paths and want to compare setup style and maintenance ownership.

The best choice depends on where you want the ownership line to sit. If you want the CI workflow and the browser test execution to stay easy for QA and DevOps to operate together, Endtest’s native Jenkins integration is the more direct fit.

Recommended implementation pattern

If I had to reduce this to one operational recommendation, it would be this:

1. Build the app in Jenkins.
2. Deploy it to a stable test environment.
3. Use the official Endtest Jenkins plugin to trigger the run.
4. Wait for completion and collect the result summary.
5. Fail the pipeline only when the Endtest result should block release.

That pattern gives you the main benefits of post-build browser testing without the usual failure traps, especially brittle credential handling, duplicated polling logic, and unclear gating.

FAQ

Can I run Endtest before the build finishes?

Not if you want the result to mean anything. Endtest should run after the artifact or environment is stable enough to test.

Does the Endtest Jenkins integration wait for the test to finish?

Yes. The plugin documentation says it can automatically poll until execution results are available.

Can Jenkins fail the build if Endtest fails?

Yes. The Jenkins integration documents optional build failure when Endtest reports failures or errors.

Should I put the App ID and App Code in the Jenkinsfile?

No. Endtest recommends storing them in Jenkins Credentials.

What if I need to run multiple Endtest executions from one request?

The Jenkins integration supports multiple executions started by the same API request, and it can aggregate the results.

Which result format should I use?

Endtest documents json and json-light result formats for the Jenkins integration. Use the one that gives your pipeline the amount of detail it actually needs.