Option to fail when license information cannot be fetched

[rjpowers10]

I'm using a pipeline in Azure DevOps Server. I have a custom PowerShell task to install and run sbom-tool.

Occasionally I will see warnings like these:

 ##[warning]Error encountered while fetching license information from API, resulting SBOM may have incomplete license information. Request returned status code: TooManyRequests

##[warning]Error encountered while fetching license information from API, resulting SBOM may have incomplete license information: The request was canceled due to the configured HttpClient.Timeout of 30 seconds elapsing.

The underlying problem may be related to #584 but I have a more general issue. I want this task to end in failure as missing the license information is a no-go for me. In other words I'd rather this warning be elevated to an error. Maybe there is a way to do this already but I haven't found one. For example, I tried changing the PowerShell task to set $WarningPreference = 'Stop' but that had no effect.

sbom-tool/src/Microsoft.Sbom.Api/Executors/LicenseInformationService.cs

Line 61 in 59a68d1

log.Warning($"Error encountered while fetching license information from API, resulting SBOM may have incomplete license information: {e.Message}");

[KalleOlaviNiemitalo]

You could collect the output to a PowerShell variable and search for that specific warning string, but that would be prone to breaking when #708 is implemented.

[rjpowers10]

As a workaround I'll probably use PowerShell to inspect the resulting JSON file to see if any of the license properties are NOASSERTION and fail accordingly.

I think that's good enough for me, but I raised the issue just to see if anyone else had thoughts or encountered the same issue.

[DaveTryon]

@rjpowers10, thanks for the suggestion! Our team is currently focusing on other areas and won't have the bandwidth to pick this up. That said, if you wanted to open a PR to implement it, we'd be happy to review and eventually merge your change. Some thoughts for the PR:

• There are a few places where you might want to make the change, depending on how much you want to define as "in scope":
  • LicenseInformationService line 61
  • LicenseInformationService line 78
  • RemapComponentDetectionErrorsToWarnings.Write
• The default behavior must remain as it currently is, and the new behavior only occurs if the command line parameter is specified
• The new behavior would ideally be exposed via both the command line and the API. If the API is changed, backward compatibility must be maintained
• The new parameters need to be documented in all entry points where it is introduced