What Is Jenkins? How to Use It for CI Testing

Jenkins is an open-source automation server that can run your project’s build and test commands whenever code changes. To use it for continuous integration (CI), install Jenkins, connect a repository, add a Jenkinsfile that defines build and test stages, then review each run’s status and console output. Jenkins orchestrates your checks; your project’s test framework does the actual testing.

1. What Jenkins is and what CI testing means

Jenkins automates tasks involved in building, testing, delivering, and deploying software. CI is the practice of integrating code changes and running checks regularly so problems can be found while they are easier to diagnose. Jenkins can run those checks on a schedule or in response to repository activity, depending on how you configure the job and source-control integration.

A Jenkins Pipeline describes that work as code. Its stages group related work—such as Build and Test—and its steps run commands or other actions. A Jenkinsfile is commonly kept in the project repository so the workflow can be reviewed and changed alongside the code. See the [Jenkins documentation](https://www.jenkins.io/doc/) and the [Pipeline overview](https://www.jenkins.io/doc/book/pipeline/).

2. What you need before setting up Jenkins

A machine or environment where Jenkins can run: Jenkins documents native package, Docker, Kubernetes, and standalone installation options across supported operating systems.
A compatible Java runtime for the Jenkins version and installation method you choose. Check the installation documentation for current requirements; requirements are version-specific.
A repository containing your application and its build and test commands.
An agent environment with the tools those commands need, such as a language runtime, compiler, package manager, or test runner.
A Jenkins Pipeline installation. Pipeline is a plugin suite and is included among the suggested plugins in the setup wizard, but available steps depend on the plugins installed on your instance.

The Jenkins guided tour’s standalone example uses Java 21 or 25 and launches a WAR with java -jar jenkins.war --httpPort=8080. Those are prerequisites and instructions for that specific tour, not universal requirements for every Jenkins installation. Follow the current installation guide for your chosen environment: [Jenkins installation documentation](https://www.jenkins.io/doc/book/installing/).

3. Create a basic Jenkins CI Pipeline

Install and initialize Jenkins. Choose the documented method that fits your operating system or infrastructure. Complete the initial setup wizard and install Pipeline support.
Confirm the project commands. Identify the commands that build the project and run its tests. Run them locally or in the intended agent environment first, so you know what Jenkins needs to execute.
Add a Jenkinsfile. Put the file at the repository root unless your job will use a different script path. The example below is a Declarative Pipeline; replace the sample shell commands with the commands your project actually uses.
Create a Pipeline job. Configure Jenkins to load the Jenkinsfile from your source-control repository. For repositories where branches should be discovered and built automatically, use a Multibranch Pipeline and ensure the script path matches the file’s location.
Run the job and read its output. Check each stage’s result and the console log. A failed stage usually points to a missing dependency, an incorrect command, or a test/build failure in the project.

Minimal Declarative Jenkinsfile

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh './build.sh'
            }
        }
        stage('Test') {
            steps {
                sh './test.sh'
            }
        }
    }
}

This is an illustrative pattern, not a universal project configuration. The commands must exist in the checked-out repository, and the selected agent must have the tools they require. On a Windows agent, use the appropriate Windows command step and project commands instead of sh. The official [Pipeline getting-started guide](https://www.jenkins.io/doc/book/pipeline/getting-started/) explains job setup and both Pipeline styles.

Example: use a project’s existing commands

There is no single Jenkins test command. A Java/Maven project, Python application, Node.js project, C++ application, or .NET project will have different build and test commands. Keep Jenkins focused on invoking the same commands the project uses; use the [Jenkins tutorials](https://www.jenkins.io/doc/tutorials/) for technology-specific learning paths.

For example, if the repository contains executable scripts named build.sh and test.sh, the sample Jenkinsfile runs them in sequence. If your project uses a package manager directly, put its real build and test commands in those stages. A successful build stage does not imply the tests passed; Jenkins reports the stages separately.

4. Choose a Pipeline style and job type

Declarative or Scripted Pipeline

Declarative Pipeline uses a structured form that is straightforward for many teams to review. Scripted Pipeline offers a Groovy-based way to define a workflow. Choose the format your team can maintain, and consult the Jenkins syntax documentation for the installed plugins and steps available on your instance. Groovy knowledge can help, but Jenkins’ getting-started material does not require it for basic Pipeline use.

Single Pipeline or Multibranch Pipeline

A Pipeline job can load a Jenkinsfile from source control for a chosen branch or configuration. A Multibranch Pipeline can discover repository branches that contain pipeline definitions and create jobs for them. The right choice depends on whether you want Jenkins to manage one configured pipeline or discover branches. Check the repository layout and configure the script path if the Jenkinsfile is not at the root. See [Creating your first Pipeline](https://www.jenkins.io/doc/pipeline/tour/hello-world/).

Agent selection

agent any asks Jenkins to run the Pipeline on an available agent. That agent must have the project’s dependencies and access to the repository and any required services. In a real installation, teams can select or label agents to match the required operating system or toolchain. The exact configuration depends on the Jenkins environment and installed plugins.

5. Keep credentials and configuration out of source

Do not put passwords, access tokens, or private keys directly in a source-controlled Jenkinsfile. Use Jenkins credential facilities for secrets and follow the current Jenkins credentials documentation for the specific binding and plugin used by your job. Limit access to credentials and agent environments to the jobs and people that need them.

Keep environment-specific settings explicit and reviewable. If a pipeline depends on a particular tool version, service, or environment variable, document that dependency and make sure the agent provides it. Plugin availability matters: a Pipeline step shown in an example may not exist on an instance without the relevant plugin.

6. Read build and test results

Build succeeds, tests fail: the project compiled or packaged, but its test command returned an error. Start with that stage’s console output.
Build stage fails: check whether the command exists, is executable, and has the required runtime and dependencies on the agent.
Job never starts: check whether an agent is online and available, and whether the job can access its configured repository.
Branch is missing: for a Multibranch job, confirm branch discovery and verify that the branch contains the Jenkinsfile at the configured script path.

Use separate stages for meaningful steps so the interface and logs show where the workflow stopped. The Jenkins Pipeline tour demonstrates creating and inspecting a first Pipeline: [Hello World Pipeline](https://www.jenkins.io/doc/pipeline/tour/hello-world/).

7. Troubleshooting common Jenkins CI problems

Symptom	Likely cause	What to check or change
`sh` step is unavailable or fails on startup	The job is running on an agent that does not support the Unix shell command step, or the environment is Windows.	Use the appropriate command step for the agent’s operating system and confirm the required shell is installed.
“No such file” for a build or test script	The command is wrong for the repository, the file is in another directory, or it is not executable.	Check the checkout layout, correct the working directory or path, and set the script’s executable permission where needed.
Dependency or runtime not found	The Jenkins agent differs from the developer’s local machine.	Install or provision the project’s required tools on the agent and confirm the versions and paths used by the job.
Jenkins cannot find the Jenkinsfile	The file is absent from the branch or the job’s script path does not match its repository location.	Commit the Jenkinsfile to the branch and correct the configured script path.
Repository checkout fails	The repository URL, network access, or authentication configuration is incorrect.	Verify the repository address and connectivity. Configure repository credentials through Jenkins’ credential facilities rather than embedding a secret in the Jenkinsfile.
A Pipeline step is unknown	The step belongs to a plugin that is not installed or available on this instance.	Check the step’s documentation and installed plugins; install and maintain plugins according to your Jenkins administration process.
Tests pass locally but fail in Jenkins	The agent may use different tool versions, environment variables, filesystem assumptions, or services.	Compare the agent environment with the project’s expected environment and inspect the failing test’s console output.
A job waits for an executor	No suitable agent is available, or all matching executors are occupied.	Check agent status, labels, capacity, and whether another job is using the required executor.

8. Performance, reliability, and cost considerations

Keep feedback useful and timely

Run the checks that give your team useful feedback, and organize them into stages so the slow or failing part is visible. Build and test duration depends on the project, dependency setup, agent resources, and test suite; there is no universal Jenkins runtime figure. Avoid adding work to every run unless it helps the team make a decision.

Make agent environments repeatable

Differences between agents and developer machines are a common source of inconsistent results. Keep toolchain requirements explicit, ensure agents have the required dependencies, and verify that jobs can reach any required repository or service. A Jenkins server coordinates work, but the agent executes the project commands.

Plan capacity and maintenance

Jenkins has no single fixed operating cost: it depends on where it is hosted, the agents and resources used, administration, and the project’s workload. Account for the server and agent capacity needed for concurrent jobs, plus the time required to maintain Jenkins and its plugins. Choose an installation method and capacity based on your environment rather than treating the guided tour as a production sizing recommendation.

Keep plugin changes controlled

Installed plugins determine many available features and steps. Track which plugins your workflows depend on, and review plugin changes as part of Jenkins maintenance. The official documentation is the source for installation and Pipeline behavior: [Jenkins User Documentation](https://www.jenkins.io/doc/).

9. Testing Jenkins itself is a different task

This guide uses Jenkins to run an application’s tests. If you are developing Jenkins or a Jenkins plugin and want to test Jenkins behavior, that is a separate workflow. The Jenkins developer guide describes a JUnit-based test harness that sets up and tears down Jenkins installations and includes helpers for jobs, agents, security realms, and source-control integrations: [Jenkins testing documentation](https://www.jenkins.io/doc/developer/testing/).

Or skip the browser setup

If your CI workflow also needs a website screenshot—for example, to capture a page during a visual check—you can call the ScreenshotNeo API instead of setting up browser capture infrastructure. ScreenshotNeo is a website screenshot API and MCP server by Yorker Media. See the [ScreenshotNeo website](https://screenshotneo.com) and [API documentation](https://screenshotneo.com/docs/).

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie and consent banners, newsletter popups, and chat widgets are removed before the shot; each cleanup step can be turned off.
Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing. Responses include X-Page-Verdict and X-Billed headers.
An MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs.
The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

FAQ

Does Jenkins include a test framework?

No. Jenkins runs the commands that invoke your project’s build and test tools; the project supplies its own framework and tests.

Does a Jenkinsfile have to be named exactly that?

That is the conventional filename. If you use another name or location, configure the job’s script path to match.

Do I need to know Groovy to start?

Not for a basic Declarative Pipeline. Scripted Pipeline uses Groovy syntax, and Groovy knowledge can help as workflows become more customized.

Can Jenkins run on Windows?

Jenkins supports Windows installations. The commands in a Pipeline must also match the operating system of the agent that runs them.

Where should I look when a pipeline fails?

Start with the failed stage and its console output. It usually shows the command that failed and the error returned by the project or agent.