Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata
The official glossary page is now located at https://jenkins.io/doc/book/glossary/ but it does not contain all terms from this page, yet.

Table of terms used in Jenkins

Term used in Jenkins



Jenkins seems to use these terms interchangeably. They all refer to runnable tasks that are controlled / monitored by Jenkins.


Result of one run of a Project.




Slaves are computers that are set up to build projects for a master. Jenkins runs a separate program called "slave agent" on slaves. When slaves are registered to a master, a master starts distributing loads to slaves. Term Node is used to refer to all machine that are part of Jenkins grid, slaves and master.


Handles creation of Nodes to dynamically expand/shrink the number of slave machines


Separated stream of builds to be run on Node in parallel. Node can have 1 or more Executors. Special executors can be created dynamically (one-off executors) to run lightweight jobs used mostly for orchestration purposes.


Disposable directory on Node used as a working directory for building. It is preserved on best effort bases after build completion.

Stable build

A build is stable if it was built successfully and no publisher reports it as unstable.

Unstable build

A build is unstable if it was built successfully and one or more publishers report it unstable. For example if the JUnit publisher is configured and a test fails then the build will be marked unstable.

Successful build

A build is successful when the compilation reported no errors.

Broken build
Failed build

A build is broken if it failed during building. That is, it is not successful.

Completed build

A build is completed, if it was started and finished with any result, including failed builds.

Upstream project

A project can have one or several upstream projects, which means that a build for the current project may be scheduled when an upstream build is finished. Per default every stable upstream build will schedule a build in the downstream project, but there are several options and plugins which can customize this behaviour.

Downstream project

A project can have one or several downstream projects. The current project is then known as an upstream project of the downstream project. See Upstream project for what this means regarding scheduling of builds.

(Un)Stable project

A project is (un)stable if its most recent (completed) build is (un)stable.

Broken project

A project is broken if its most recent (completed) build is broken.


A publisher is part of the build process other than compilation, for example JUnit test runs. A publisher may report stable or unstable result depending on the result of its processing. For example, if a JUnit test fails, then the whole JUnit publisher may report unstable.

Classes Terms Specific to Writing Plugins / Understanding Code Architecture

Term used in Jenkins


  • No labels


  1. Unknown User (kcbaltz)

    From "Downstream Project" above:

    It is possible to setup that it should add the downstream project to the call queue even if the current project is unstable (default is off)

    How can this be done with Maven projects that auto-configure their downstream builds?  If you use the explicit "Build projects after", there's a checkbox to say "build even if unstable".  However, no such checkbox appears to exist for downstream Maven projects.

  2. Unknown User (scanguskhan)

    Can anybody explain or point to some documentation exactly how Jenkins classifies upstream/downstream relationships  in regards to multi-module maven projects.?

    How does Jenkins clasify a multi-module maven project job, in relation  to a separate job that builds only one of those multi-modules, but where that separate  module job also specifies the multi-module's pom as its parent pom?

    For example, since pom inheritance mean parent pom chnages can break the child build, I would think that all parent jobs  must be classified as upstream to any maven jobs where that parent pom is inherited   Now the second after I rationalize that usuage of pom inheritence obviously nessesitates  that Jenkins must  classify the parent pom project as upstream to the child job,   I find a bunch cases where usuage of pom inheritence does not classify the parent as upstream to the child.

    Does Jenkins even consider pom inheritance in classification of upstream/downstream jobs?

  3. Unknown User (kutzi)

    Please post questions to the user mailing list or the IRC channel

  4. Unknown User (aartemov)

    Here also should be added the following terms definitions:

    project, build

    As I understand, they have mostly the same meaning as the job term. Especially job and build and task.

  5. Unknown User (tschoen0620)

    Please - as a new person trying to understand what this is all about, add more terms to your list, as suggested by Alexander. 

    When to use Jenkins would help too....why use Jenkins over sceduled tasks, etc.     How do things get added to work space?    What is to be added to work space.    

    It seems you're making huge assumptions that whoever uses Jenkins is already supposed to understand everything talked about.   

  6. Unknown User (ashokekumars)

    Can someone please give more elaboration on the difference between Project & JOB in Jenkins please

    1. Unknown User (aartemov)

      As I already found out that "build" is the result of any job or project execution. But the difference between project and job I still left unknown for me. It looks like these terms are about the same thing and it really confuses. it is important for me, because I'm trying to teach people to use Jenkins.