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)