JBrowning340945 (Community Member) asked a question.
Has "failTheBuildIfVeracodeScanDidNotInitiate" changed to "failBuildIfUploadAndScanBuildStepFails"?
We have a build not failing (when it should).
We are setting "failTheBuildIfVeracodeScanDidNotInitiate=True" but the DevOps pipeline step is completing (OK/Green Tick etc) but the log says different and the scan does actually fail with the below...
"...Exiting Veracode Upload and Scan Task: App not in state where new builds are allowed."
.png){kind=logo}
Hello @JBrowning340945 (Community Member) ,
There are no wide spread issue with this setting that we are aware of. Would you be willing to message me privately, the snippet of code for the step that you are having issues with? I can take a look at it to see if I can assist.
Jason
Veracode Support Engineer
@JBrowning340945 (Community Member) ,
It has been a few days and just wanted to ensure that you saw my post from last week.
Jason
Veracode Support Engineer
I realize this question is 10 months old but I have the exact same question which wasn't really answered.
We have multiple Azure DevOps YAML pipelines that use the "Veracode.veracode-vsts-build-extension.veracode-scanner-task.Veracode@3" task and are specifying 'failTheBuildIfVeracodeScanDidNotInitiate: true' but we're seeing that step and the whole build succeed in some instances where it shouldn't (e.g. concurrent static scan limit exceeded). Looking at the current documentation, this property is not listed but there is a similarly named 'failBuildIfUploadAndScanBuildStepFails' instead that sounds pretty similar.
Answers from support ticket:
- only "failBuildIfUploadAndScanBuildStepFails" is supported,
- the old value does not work,
- there is no difference in functionality.
This was changed in the middle of the last year (with version 3.6.0). We do typically mention these breaking changes in the Release Notes, including any new parameters we add but it appears that failTheBuildIfVeracodeScanDidNotInitiate was never mentioned in the docs. Instead, it should have been announced in the Release Notes as a replacement/rename of an existing parameter.