Issue Tracking

Skip to end of metadata
Go to start of metadata

This page describes guidelines for reporting an issue (bug, improvement, new feature, patch or task) and the steps in its lifecycle.

Jenkins uses JIRA, at

Reporting an issue


  • Check that this is a bug in Jenkins itself and not a general build problem. i.e. try to build your project outside Jenkins, but on the same machine where Jenkins master (or the particular slave node) is running.
  • Search JENKINS' JIRA for an issue similar to the one you might want to create. If you have a stacktrace try to search for the description in the outmost frame.
  • If you're not on the newest version, you may also check the changelog if the issue is already fixed in a more recent version. If it's a problem in plugin, look in the Wiki for plugin changelogs.
  • File your issue with the right type (bug, improvement, new feature, patch or task) in JENKINS' JIRA, choosing the right component.
  • Are you able to work around the issue or has it stopped your usage of Jenkins in its tracks? This should probably be a hint how to define the priority:
  • If the issue is a security vulnerability, please report it under the SECURITY project, which is restricted access. Discussions of such issues should also be directed to, not the usual dev list. Also see Security Advisories.
Priority Description
Blocker Blocks development and/or testing work, production could not run.
Critical Crashes, loss of data, severe memory leak.
Major Major loss of function.
Minor Minor loss of function, or other problem where easy workaround is present.
Trivial Cosmetic problem like misspelt words or misaligned text.

What to put in the description of an issue report?

  • In what version of Jenkins is this bug occurring or you do miss a feature, want an improvement? If this issue is (likely) related to plugins, please also include the plugins' versions.
  • What environment are you using? Hint: You should attach the information from http://SERVER/systemInfo wrapped by a {noformat} tag on each side for readability.
  • How are you running Jenkins?
    • Using the executable war like java -jar jenkins.war
    • Using another container as Tomcat or Jetty.
    • Have you specified additional parameters for the Java VM (Heapspace etc.)?
    • Did you just install the deb or rpm?
    • With which Java VM (Oracle, IBM etc.)?
    • On which operating system? 32- or 64-bit?
  • Include stacktraces from the log if any.
  • Did this error start occurring after an upgrade?
    • What version did you upgrade to/from?
    • Is this your first install?
  • If this is an issue in the collaboration with another system (e.g. a SCM), please also provide the type and the version of the other system

Lifecycle of an issue

Definitions of states

See description in JENKINS' JIRA and the definitions in the JIRA documentation as well.

State Description
OPEN The issue is open and ready for the assignee to start work on it.
IN PROGRESS This issue is being actively worked on at the moment by the assignee.
RESOLVED A resolution has been taken and it is awaiting verification by reporter. From here issues are either reopened or are closed.
CLOSED The issue is considered finished, the resolution is correct, the artifact with the fix is released. Issues which are closed can be reopened.
REOPENED This issue was once resolved, but the resolution was deemed incorrect. From here issues are handled like before again.

Usual workflows


  1. Reporter creates a new issue and provides all available information during creation or while chatting with the assignee.
  2. Assignee starts work, optionally setting state to IN PROGRESS and RESOLVEs the issue by a fix in SCM. If the assignee includes [FIXED JENKINS-XYZ], [FIXES JENKINS-XYZ] or [FIX JENKINS-XYZ] in her SCM message, the transition to RESOLVED will happen automatically.
  3. Issue may only be CLOSED when the fix is released (with core this usually only takes one week, with plugins the fix might be sitting in the SCM alone for a while ). This will happen automatically in the near future (as of 2011/02/11) by extending the HPI release process.
  4. So the Assignee should release often, release early .


  1. Reporter creates a new issue and provides all available information during creation or while chatting with the assignee.
  2. Assignee, reporter or another developer resolves the issue to be a DUPLICATE.
  3. Periodically a job will go through RESOLVED DUPLICATE issues without a code change and transition them to CLOSED, when the DUPLICATED issue is CLOSED.
This is work in progress, just starting to collect ideas from the Jenkins Developer List.
TODO: Include more information from Proposed Hudson/Jenkins Bug Triage Procedures, JIRA Workflow Updates/Status and
"Verified" Issues.

Quick Links

If you want to link to a Jenkins bug with a short URL, use e.g.: instead of


issue-tracking issue-tracking Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Add Comment