Class GherkinToAsciidocExtension
gherkinToAsciidoc {
sourceDirs.from('src/test/resources/features') // default
includeSubDirs = true // default
outputDir = layout.buildDirectory.dir('generated-docs') // default
outputFileName = 'features.adoc' // default
trackProgress = false // default
// glueCodeDirs.from('src/test/java/.../steps') // required when trackProgress = true
groupByFeature = true // default; forced to true whenever trackProgress = true
// snippetDir = layout.buildDirectory.dir('generated-docs/features/snippets') // default
// template = file('templates/report.mustache') // optional
// systemUnderTestVersion = 'v1.0.0' // optional; default: project.version
indexing = IndexingMode.OFF // default; requires includeSubDirs = true
forceRewrite = false // default; see getForceRewrite()
consolidatedIndex = false // default; see getConsolidatedIndex()
trackProgressHistory = false // default; requires trackProgress = true
// progressHistoryFile = layout.projectDirectory.file('gherkin-progress-history.ndjson') // default
updateProgressHistory = trackProgressHistory // default; see getUpdateProgressHistory()
failOnDuplicateScenarios = true // default; see getFailOnDuplicateScenarios()
}
indexing, forceRewrite, and updateProgressHistory can each be overridden for
the whole build from the command line, e.g. -PgherkinToAsciidoc.indexing=ci - see
getIndexing(), getForceRewrite(), and getUpdateProgressHistory().
-
Field Summary
FieldsModifier and TypeFieldDescriptionstatic final StringDefault name of the generated AsciiDoc output file.static final StringDefault name of the persisted scenario progress history file.static final StringDefault relative path of the directory report snippets are written to.static final StringDefault relative path of the source directory containing.featurefiles.static final StringName of the Gradle project property that overridesgetForceRewrite()from the command line for every project in the build, e.g.static final StringName of the Gradle project property that overridesgetIndexing()from the command line for every project in the build, e.g.static final StringExtension DSL block name, i.e.static final StringName of the Gradle project property that overridesgetUpdateProgressHistory()from the command line for every project in the build, e.g. -
Constructor Summary
ConstructorsConstructorDescriptionFor use by the Gradle-generated concrete subclass. -
Method Summary
Modifier and TypeMethodDescriptionabstract org.gradle.api.provider.Property<Boolean> In a multi-project Gradle build, whethergetIndexing()'sFeaturenumbering (and, forIndexingMode.SCENARIO, its cross-fileScenarionumbering too) is one continuous sequence spanning every project in the build, or an independent sequence - starting at 1 again - for each project.abstract org.gradle.api.provider.Property<Boolean> WhethergenerateFeatureDocsfails the build when two or more scenarios within the same project share a title.abstract org.gradle.api.provider.Property<Boolean> WhethergetIndexing()renumbers everyFeature/Scenariofrom scratch (ignoring any existing numbers), or only numbers the ones that aren't already correctly numbered for the currently configuredIndexingMode.abstract org.gradle.api.file.ConfigurableFileCollectionDirectories containing the Cucumber-JVM glue code (step definitions) used to determine whether a scenario's steps are implemented.abstract org.gradle.api.provider.Property<Boolean> Whether to group scenarios by their enclosingFeaturein the generated AsciiDoc, instead of a flat list.abstract org.gradle.api.provider.Property<Boolean> Whether to recursively scan sub-directories of every configured directory ingetSourceDirs().abstract org.gradle.api.provider.Property<IndexingMode> Whether - and how - to numberFeature/Scenariotitles directly in the source.featurefiles.abstract org.gradle.api.file.DirectoryPropertyDirectory where the generated AsciiDoc file will be written.abstract org.gradle.api.provider.Property<String> Name of the generated AsciiDoc file (without path).abstract org.gradle.api.file.RegularFilePropertyFile that the persisted scenario progress history is read from and, whengetUpdateProgressHistory()istrue, written back to.abstract org.gradle.api.file.DirectoryPropertyDirectory that thelisted.adoc/defined.adoc/implemented.adocreport snippets are written to whengetTrackProgress()istrue.abstract org.gradle.api.file.ConfigurableFileCollectionSource directories that contain the.featurefiles to process.abstract org.gradle.api.file.RegularFilePropertyA single.featurefile to process.abstract org.gradle.api.provider.Property<String> Version of the system under test that the reported Gherkin scenarios exercise, printed in the generated document as e.g.abstract org.gradle.api.file.RegularFilePropertyOptional Mustache template used to render the generated AsciiDoc file so that it references the report snippets viainclude::directives, instead of embedding their content verbatim.abstract org.gradle.api.provider.Property<Boolean> Whether to classify every scenario aslisted,defined, orimplementedand include a progress summary in the generated AsciiDoc.abstract org.gradle.api.provider.Property<Boolean> Whether to persist, across builds, a per-scenario history of when each scenario first reachedlisted,defined, andimplementedstatus - surviving scenarios being moved between feature files, since the history is keyed by a fingerprint of the scenario's name rather than by feature file location.abstract org.gradle.api.provider.Property<Boolean> WhethergetProgressHistoryFile()is written back to disk after being updated with the current run's scenarios.
-
Field Details
-
NAME
Extension DSL block name, i.e. the name used to register the extension with the project.- See Also:
-
DEFAULT_SOURCE_DIR
Default relative path of the source directory containing.featurefiles.- See Also:
-
DEFAULT_OUTPUT_FILE_NAME
Default name of the generated AsciiDoc output file.- See Also:
-
DEFAULT_SNIPPET_DIR
Default relative path of the directory report snippets are written to.- See Also:
-
DEFAULT_PROGRESS_HISTORY_FILE_NAME
Default name of the persisted scenario progress history file.- See Also:
-
INDEXING_OVERRIDE_PROPERTY
Name of the Gradle project property that overridesgetIndexing()from the command line for every project in the build, e.g.-PgherkinToAsciidoc.indexing=ci. Takes precedence over any project's own configuredindexingvalue. The value is matched againstIndexingModeenum constant names case-insensitively.- See Also:
-
FORCE_REWRITE_OVERRIDE_PROPERTY
Name of the Gradle project property that overridesgetForceRewrite()from the command line for every project in the build, e.g.-PgherkinToAsciidoc.forceRewrite=true. Takes precedence over any project's own configuredforceRewritevalue. The value is parsed as a boolean.- See Also:
-
UPDATE_PROGRESS_HISTORY_OVERRIDE_PROPERTY
Name of the Gradle project property that overridesgetUpdateProgressHistory()from the command line for every project in the build, e.g.-PgherkinToAsciidoc.updateProgressHistory=true. Takes precedence over any project's own configuredupdateProgressHistoryvalue. The value is parsed as a boolean.- See Also:
-
-
Constructor Details
-
GherkinToAsciidocExtension
public GherkinToAsciidocExtension()For use by the Gradle-generated concrete subclass.
-
-
Method Details
-
getSourceDirs
public abstract org.gradle.api.file.ConfigurableFileCollection getSourceDirs()Source directories that contain the.featurefiles to process. One or more directories may be configured, e.g. viasourceDirs.from(file('a'), file('b')). Mutually exclusive withgetSourceFile().- Returns:
- mutable file collection of feature file source directories
-
getSourceFile
public abstract org.gradle.api.file.RegularFileProperty getSourceFile()A single.featurefile to process. Mutually exclusive withgetSourceDirs().- Returns:
- mutable file property for a single feature file
-
getIncludeSubDirs
Whether to recursively scan sub-directories of every configured directory ingetSourceDirs(). Defaults totrue. Forced totruewhenevergetTrackProgress()istrue.- Returns:
- mutable boolean property controlling recursive directory scanning
-
getOutputDir
public abstract org.gradle.api.file.DirectoryProperty getOutputDir()Directory where the generated AsciiDoc file will be written. Defaults tobuild/generated-docs.- Returns:
- mutable directory property for the output directory
-
getOutputFileName
Name of the generated AsciiDoc file (without path). Defaults to "features.adoc".- Returns:
- mutable string property for the output file name
-
getTrackProgress
Whether to classify every scenario aslisted,defined, orimplementedand include a progress summary in the generated AsciiDoc. Defaults tofalse.Can only be enabled when
getSourceDirs()andgetGlueCodeDirs()are both configured; enabling it also impliesgetIncludeSubDirs().- Returns:
- mutable boolean property controlling progress tracking
-
getGlueCodeDirs
public abstract org.gradle.api.file.ConfigurableFileCollection getGlueCodeDirs()Directories containing the Cucumber-JVM glue code (step definitions) used to determine whether a scenario's steps are implemented. One or more directories may be configured, e.g. viaglueCodeDirs.from(file('a'), file('b')). Required whengetTrackProgress()istrue; ignored otherwise.- Returns:
- mutable file collection of glue code directories
-
getGroupByFeature
Whether to group scenarios by their enclosingFeaturein the generated AsciiDoc, instead of a flat list. Defaults totrue. Forced totruewhenevergetTrackProgress()istrue, in which case scenarios are grouped by feature within each of the listed/defined/implemented sections.- Returns:
- mutable boolean property controlling grouping by feature
-
getSnippetDir
public abstract org.gradle.api.file.DirectoryProperty getSnippetDir()Directory that thelisted.adoc/defined.adoc/implemented.adocreport snippets are written to whengetTrackProgress()istrue. Defaults tobuild/generated-docs/features/snippets.When
getGroupByFeature()istrue, snippets for a status with at least one scenario are written per feature, under<snippetDir>/<camelCaseFeatureTitle>/<status>.adoc.- Returns:
- mutable directory property for the snippet output directory
-
getTemplate
public abstract org.gradle.api.file.RegularFileProperty getTemplate()Optional Mustache template used to render the generated AsciiDoc file so that it references the report snippets viainclude::directives, instead of embedding their content verbatim. Only consulted whengetTrackProgress()istrue; ignored otherwise.When not set, the generated report looks exactly as it does without this property: scenario titles are embedded directly, with no
include::directives. The snippet files are still written either way.- Returns:
- mutable file property for the Mustache template file
-
getSystemUnderTestVersion
Version of the system under test that the reported Gherkin scenarios exercise, printed in the generated document as e.g.System Under Test version: v1.0.0. Defaults to the project's ownversion(as set in the build file or a properties file); set this property to override that default, e.g. when the scenarios target a different artifact than the one being built.- Returns:
- mutable string property for the system-under-test version
-
getIndexing
Whether - and how - to numberFeature/Scenariotitles directly in the source.featurefiles. Defaults toIndexingMode.OFF.IndexingMode.OFF- nothing is numbered (default).IndexingMode.FEATURE- every feature is numbered, e.g.Feature: 1 - User authentication.IndexingMode.SCENARIO- every scenario is numbered continuously across all feature files, e.g.Scenario: 1 - User logs in.IndexingMode.ALL- both are numbered, scenarios as<featureNumber>.<scenarioNumber>, e.g.Scenario: 1.1 - User logs in.IndexingMode.CI- indexing is skipped entirely; unlikeIndexingMode.OFF, the source files aren't even stripped of prior numbering. See "gherkinToAsciidoc.indexing" below.
Feature files are processed in the same order the generated report lists them in: for each source directory (directories themselves ordered alphabetically by path when more than one is configured), that directory's own feature files first - alphabetically by file name - and only then, when
getIncludeSubDirs()istrue, its sub-directories' files, each sub-directory visited the same way, alphabetically by name. Scenario numbers additionally follow document order within each file. A line whose existing number already reflects the currently configured mode is left untouched, rather than being renumbered to fit that processing order - seegetForceRewrite()for exactly what "reflects the currently configured mode" means and how to opt out of it.IndexingMode.OFFandIndexingMode.CIare always allowed.IndexingMode.FEATURE,IndexingMode.SCENARIO, andIndexingMode.ALLare only allowed whengetIncludeSubDirs()istrue; whengetGroupByFeature()isfalse, onlyIndexingMode.SCENARIOof those three is allowed.The "gherkinToAsciidoc.indexing" project property, when set (e.g.
-PgherkinToAsciidoc.indexing=ci), overrides this property for every project in the build regardless of what any project configures here - typically used to forceIndexingMode.CIin a CI pipeline sogenerateFeatureDocsnever mutates source files there, without having to change the build script itself.- Returns:
- mutable property for the indexing mode
-
getForceRewrite
WhethergetIndexing()renumbers everyFeature/Scenariofrom scratch (ignoring any existing numbers), or only numbers the ones that aren't already correctly numbered for the currently configuredIndexingMode. Defaults tofalse. Has no effect whengetIndexing()isIndexingMode.OFF(which always strips every number, regardless) orIndexingMode.CI(which never touches anything, regardless).true- everyFeature/Scenarionumber is recomputed from scratch, exactly as if none of them had ever been numbered before - the same behaviour as before this property existed.false(default) - a line whose existing number already matches the formatgetIndexing()'s mode would itself produce is left completely untouched: for aFeature, a single integer; for aScenario/Scenario Outline, either a single integer (IndexingMode.SCENARIO) or<featureNumber>.<n>matching that scenario's own feature's number (IndexingMode.ALL). Every other numbered line - the wrong format, or a leftover from a previously configured, differentindexingvalue - is stripped and renumbered, same astrue. A newly added feature file that happens to sort alphabetically before already-numbered files is given the next number not already in use, rather than bumping every already-numbered file after it.
For example, with
indexing = IndexingMode.SCENARIOandforceRewrite = false, aScenarioalready readingScenario: 3 - ...keeps that number. ChangingindexingtoIndexingMode.ALLaffords that same scenario a fresh number - its old3doesn't matchALL's<featureNumber>.<n>format, so it no longer "reflects" the currently configured mode.The "gherkinToAsciidoc.forceRewrite" project property, when set (e.g.
-PgherkinToAsciidoc.forceRewrite=true), overrides this property for every project in the build regardless of what any project configures here.- Returns:
- mutable boolean property controlling whether existing numbering is preserved
-
getConsolidatedIndex
In a multi-project Gradle build, whethergetIndexing()'sFeaturenumbering (and, forIndexingMode.SCENARIO, its cross-fileScenarionumbering too) is one continuous sequence spanning every project in the build, or an independent sequence - starting at 1 again - for each project. Defaults tofalse. Has no effect whengetIndexing()isIndexingMode.OFForIndexingMode.CI(neither numbers anything), and no effect onIndexingMode.ALL'sScenarionumbering, which is already scoped perFeature- strictly finer-grained than per-project - regardless.false(default) - every project numbers its own features (and, inIndexingMode.SCENARIOmode, scenarios) from 1, independently of every other project in the build - so two projects maintained concurrently never fight over the same numbers, and a project's own numbers don't shift just because another project gained or lost a feature file.true- every project's features (andIndexingMode.SCENARIOscenarios) instead share one number space across the whole build, exactly as if every project's feature files had been passed to a single project's owngenerateFeatureDocs- the behaviour every version of this plugin had before this property existed. Set this when existing numbers already reference this shared, build-wide sequence and renumbering every project's features to start at 1 would be disruptive.
Only affects a task that actually scans more than one project's feature files. The scoping happens within a single
generateFeatureDocsinvocation, over exactly the files that invocation collected - so it matters only in an "aggregator" layout, where one project'ssourceDirsreach into several projects. In the more common "fan-out" layout, where the plugin is applied to every project and each task'ssourceDirsresolve against its own project directory, no task ever sees another project's files: numbering already restarts at 1 in every project, and setting this totrueis silently ignored rather than producing the build-wide sequence described above. See the README's "Multi-Project Builds" section for both layouts.Like
getIndexing()andgetForceRewrite(), this property is inherited from the root project's owngherkinToAsciidocextension by default; a sub-project that configures it itself overrides that inherited default for itself only.- Returns:
- mutable boolean property controlling whether indexing is consolidated build-wide or scoped per project
-
getTrackProgressHistory
Whether to persist, across builds, a per-scenario history of when each scenario first reachedlisted,defined, andimplementedstatus - surviving scenarios being moved between feature files, since the history is keyed by a fingerprint of the scenario's name rather than by feature file location. Defaults tofalse.Requires
getTrackProgress()to also betrue; enabling this property whiletrackProgressisfalsefailsgenerateFeatureDocswith a descriptive error. The history file configured viagetProgressHistoryFile()is always read when this property istrue, regardless ofgetUpdateProgressHistory().The plugin itself has no dependency on git or any other version control system; branch-based control over when to advance the history (e.g. "only on
main") is a CI concern, expressed purely throughgetUpdateProgressHistory()- typically driven from a Gradle property set differently per branch in the CI pipeline itself.- Returns:
- mutable boolean property controlling whether scenario progress history is tracked
-
getProgressHistoryFile
public abstract org.gradle.api.file.RegularFileProperty getProgressHistoryFile()File that the persisted scenario progress history is read from and, whengetUpdateProgressHistory()istrue, written back to. Defaults togherkin-progress-history.ndjsondirectly in the project directory - deliberately not underbuild/, since this file is meant to be committed to version control so the history survives across checkouts. Only consulted whengetTrackProgressHistory()istrue.- Returns:
- mutable file property for the progress history file
-
getUpdateProgressHistory
WhethergetProgressHistoryFile()is written back to disk after being updated with the current run's scenarios. Defaults to the same value asgetTrackProgressHistory(). Only consulted whengetTrackProgressHistory()istrue; the history file is always read regardless of this property's value, so a build with this set tofalsestill reports against the up-to-date-in-memory history, it simply doesn't persist it.Set this to
falsefor branches/builds that shouldn't advance the committed history (e.g. feature branches or pull request builds), and leave ittrue(the default, oncetrackProgressHistoryis enabled) for the branch(es) that should - typically expressed via the "gherkinToAsciidoc.updateProgressHistory" project property from the CI pipeline rather than hardcoded in the build script, since the plugin itself has no notion of which branch is currently checked out.The "gherkinToAsciidoc.updateProgressHistory" project property, when set (e.g.
-PgherkinToAsciidoc.updateProgressHistory=true), overrides this property for every project in the build regardless of what any project configures here.- Returns:
- mutable boolean property controlling whether the progress history file is written back
-
getFailOnDuplicateScenarios
WhethergenerateFeatureDocsfails the build when two or more scenarios within the same project share a title. Defaults totrue.Titles are compared within each project, never across them: two microservices implementing the same cross-cutting concern legitimately carry the same scenario titles, and each keeps its own progress history for its own copy. Only a collision inside one project is a defect.
A shared title is unsafe because
ScenarioFingerprintidentifies a scenario by its title alone; two scenarios that merely happen to share a title are indistinguishable to it, so persisting progress history for them would silently corrupt it - seeDuplicateScenarioTitlesfor the full explanation. With the defaulttrue,generateFeatureDocsrejects the build outright the moment such a collision is found, before either the report or the history file is written.Set to
falseto let the build continue despite duplicate titles instead - every duplicate is still reported, as a warning, unconditionally (not only under--info, unlike the default's own pre-failure logging). Doing so also unconditionally disables progress history tracking forgenerateFeatureDocs, regardless ofgetTrackProgressHistory()'s own value: once duplicate titles are no longer guaranteed to fail the build, the fingerprint-keyed history can no longer be trusted, so it is never read, advanced, or written while this property isfalse. The generated report prominently warns about this whenevergetTrackProgressHistory()istrue.- Returns:
- mutable boolean property controlling whether duplicate scenario titles fail the build
-