The following plugin provides functionality available through Pipeline-compatible steps. Read more about how to integrate steps into your Pipeline in the Steps section of the Pipeline Syntax page.

For a list of other such plugins, see the Pipeline Steps Reference page.

Cucumber reports

cucumber: Cucumber reports

Publishes Cucumber results

This plugin requires that you use cucumber library to generate a json report. The plugin uses the json report to produce html reports that are available from jenkins on the build page after a build has run.

	import cucumber.junit.Cucumber;
	import org.junit.runner.RunWith;

	@RunWith(Cucumber.class)
	@Cucumber.Options(format = {"pretty", "html:target/cucumber", "json:target/cucumber.json"})
	public class MyTest {

	}
  • fileIncludePattern : String

    Filter for the files that should be processed. Leave empty to use default pattern **/*.json.

  • buildStatus : String (optional)

    Build result to which the build should be set when the report is marked as failed or unstable.

  • classifications (optional)

    Configure additional information as key-value displayed on main page of the report.

      Array / List of Nested Object

      Pairs key-value which are passed to the report to be displayed.

    • key : String

      Name of the classification.

    • value : String

      Value of the classification. Hyperlink, HTML code and Jenkins variable can be used for values, check Token Macro Plugin for details.

  • classificationsFilePattern : String (optional)

    Filter for the properties files that should be processed as classifications. Leave empty to use default pattern **/*.properties. The pattern is evaluated relative to jsonReportDirectory

  • customCssFiles : String (optional)

    Comma separated list of CSS files or patterns (relative to workspace) to include into all report pages.

  • customJsFiles : String (optional)

    Comma separated list of JS files or patterns (relative to workspace) to include into all report pages.

  • expandAllSteps : boolean (optional)
  • failedAsNotFailingStatus : boolean (optional)

    Failed statuses for the step is counted as not failing status and does not fail scenario.

  • failedFeaturesNumber : int (optional)

    Maximum number of failed features above which build result is triggered. Provide value -1 if the rule should be skipped.

  • failedFeaturesPercentage : double (optional)

    Maximum percentage of failed features above which build result is changed.

  • failedScenariosNumber : int (optional)

    Maximum number of failed scenarios above which build result is triggered. Provide value -1 if the rule should be skipped.

  • failedScenariosPercentage : double (optional)

    Maximum percentage of failed scenarios above which build result is changed.

  • failedStepsNumber : int (optional)

    Maximum number of failed steps above which build result is triggered. Provide value -1 if the rule should be skipped.

  • failedStepsPercentage : double (optional)

    Maximum percentage of failed steps above which build result is changed.

  • fileExcludePattern : String (optional)

    Filter for the files that should be excluded from the report.

  • hideEmptyHooks : boolean (optional)
  • jsonReportDirectory : String (optional)

    Directory where the JSON cucumber reports are located. By default and for empty value whole workspace is scanned.

  • mergeFeaturesById : boolean (optional)

    Merge features with different JSON files that have same ID so scenarios are be stored in single feature.

  • mergeFeaturesWithRetest : boolean (optional)

    Merge features and scenarios from different JSON files of different runs into a single report by features and scenarios ids.

    Example:
    Original cucumber report is "cucumber.json". Let's look a situation when couple of tests failed there. Cucumber runner generates a new report, for example, cucumber-rerun.json as a result of rerun the failed tests.
    In that case you will have a merged report where all failed tests from the original cucumber.json file are overridden with the results from the cucumber-rerun.json.

  • pendingAsNotFailingStatus : boolean (optional)

    Pending statuses for the step is counted as not failing status and does not fail scenario.

  • pendingStepsNumber : int (optional)

    Maximum number of pending steps above which build result is triggered. Provide value -1 if the rule should be skipped.

  • pendingStepsPercentage : double (optional)

    Maximum percentage of pending steps above which build result is changed.

  • reportTitle : String (optional)
  • skipEmptyJSONFiles : boolean (optional)

    Skip empty JSON reports. If this flag is not selected then report generation fails on empty file.

  • skippedAsNotFailingStatus : boolean (optional)

    Skipped statuses for the step is counted as not failing status and does not fail scenario.

  • skippedStepsNumber : int (optional)

    Maximum number of skipped steps above which build result is triggered. Provide value -1 if the rule should be skipped.

  • skippedStepsPercentage : double (optional)

    Maximum percentage of skipped steps above which build result is changed.

  • sortingMethod : String (optional)

    This section allows to configure what is default sorting method for features:

    • NATURAL - keeps same order as it was in JSON file
    • ALPHABETICAL - sorts rows alphabetically
  • stopBuildOnFailedReport : boolean (optional)

    The default behaviour is to carry on with the build even if the cucumber report contains failures. This option stops the build. Particularly useful when for example there is a need for all tests to pass before deploying to production. Note that this overrides the Build Status option, and it always marks the build as failed.

  • trendsLimit : int (optional)

    Number of historical reports that should be presented.

    • set to -1 so trends won't be displayed and history won't be stored
    • set to 0 then all historical reports will be stored and displayed
    • set to other positive value to decide how many historical reports should be presented by trends.
  • undefinedAsNotFailingStatus : boolean (optional)

    Undefined statuses for the step is counted as not failing status and does not fail scenario.

  • undefinedStepsNumber : int (optional)

    Maximum number of undefined steps above which build result is triggered. Provide value -1 if the rule should be skipped.

  • undefinedStepsPercentage : double (optional)

    Maximum percentage of undefined steps above which build result is changed.


Was this page helpful?

Please submit your feedback about this page through this quick form.

Alternatively, if you don't wish to complete the quick form, you can simply indicate if you found this page helpful?

    


See existing feedback here.