Configuring the Build Step in YAML

If you want to configure the build step in a YAML file, follow the below example.

Before you proceed, note that YAML is whitespace sensitive. Please copy and paste the example in a text editor with syntax highlighting (e.g. Notepad++).

For information on the YAML schema, see the Microsoft reference guide for Azure Pipelines YAML schema.

SpecFlow+LivingDoc custom build step YAML example:

 steps:
-task: techtalk.techtalk-specflow-plus.specflow-plus.SpecFlowPlus@0
  displayName: 'SpecFlow+ build step SpecFlow.Plus.Runner.Specs'
  inputs:
    projectFilePath: Tests/SpecFlow.Plus.Runner.Specs/Features
    projectName: testName
    testExecutionJson: 'Tests/SpecFlow.Plus.Runner.Specs/**/TestExecution.json'
    projectLanguage: en
    workItemPrefix: testPrefix
    bindingAssemblies: MyProject/**/MyBindings.dll
  enabled: false
  continueOnError: true
  condition: always()
  timeoutInMinutes: 10

bindingAssemblies example for multiple Binding assemblies:

 steps:
-task: techtalk.techtalk-specflow-plus.specflow-plus.SpecFlowPlus@0
  displayName: 'SpecFlow+ build step SpecFlow.Plus.Runner.Specs'
  inputs:
    projectFilePath: Tests/SpecFlow.Plus.Runner.Specs/Features
    projectName: testName
    projectLanguage: en
    workItemPrefix: testPrefix
    bindingAssemblies: |
     MyProject/**/MyStepDefinitions.dll
     MyProject/**/MyBindings.dll
  enabled: false
  continueOnError: true
  condition: always()
  timeoutInMinutes: 10

• task: techtalk.techtalk-specflow-plus.specflow-plus.SpecFlowPlus@0

  • @value is the task version number

• displayName: (required)

LivingDoc specific parameters (inputs):

• projectFilePath: The folder containing the feature files or the path of a .NET Full FrameWork project file containing the feature files (required)

• projectName: The name of the project visible in the viewer

• testExecutionJson: The absolute or relative path to the Test Execution JSON files generated by the SpecFlow.Plus.LivingDocPlugin. Glob patterns are supported

  Important: In order to correctly display the execution results, you MUST provide the Test Project Root folder and not a subfolder (e.g. not the Features folder) in the projectFilePath parameter.

• projectLanguage: The language used by your Gherkin files. This is optional because in many cases the language can be auto-detected. You can read more about language options here.

• workItemPrefix: The special prefix for tags used to add a link to a work item in Azure DevOps.

• bindingAssemblies Path to Binding Assemblies (newline delimited). If your Bindings are in the same Test Assembly as your feature files, enter the path to your Test Assembly. Glob patters are supported e.g.: MyProject/**/MyBindings.dll.

  For example, setting this to “DEVOPS_WI:” will allow you to tag a feature with @DEVOPS_WI:1234, and this tag will be converted to a link to work item 1234 when viewing the feature in LivingDoc.

Non-LivingDoc specific parameters:

• enabled: boolean (not needed when true)

• continueOnError: boolean (not needed when false)

• condition:

selection	YAML value
Only when all previous tasks have succeeded	(nothing)
Even if a previous task has failed, unless the build was canceled	succeededOrFailed()
Even if a previous task has failed, even if the build was canceled	always()
Only when a previous task has failed	failed()
Custom conditions	(custom condition)

• timeoutInMinutes: Specifies the maximum time, in minutes, that a task is allowed to execute before being canceled by server (zero value indicates an infinite timeout)