Task randomly fails with 'Error code 5' about psrule-pipelines HOT 4 CLOSED

will try that, thanks!

from psrule-pipelines.

@dkaubar Thanks for logging the issue.

We might need to enable verbose logging to understand what error code 5 is related to, as it is not a PSRule specific error. It means access denied.

However I suspect that the issue may be related to the inputType parameter.

For bicep expansion to work, inputType needs to be set to repository.

For example:

      - task: ps-rule-assert@1
        displayName: "Run PSRule scan"
        inputs:
          path: "$(System.DefaultWorkingDirectory)"
          inputType: "repository"
          inputPath: "$(projectDirectory)/devops/infrastructure/bicep/*.bicep"
          modules: "PSRule.Rules.Azure"
          outputFormat: "NUnit3"
          outputPath: "$(Pipeline.Workspace)/PSRule/ps-rule-results.xml"

See Creating your pipeline for additional required configuration.

If that does not resolve the issue. Can you please enable verbose logging by setting the SYSTEM_DEBUG pipeline variable to true.

This should generate a lot of additional output and should give us an idea where the problem is.

from psrule-pipelines.

so far I was not able to reproduce the issue with inputType: repository

I would however like to ask a bit about this configuration:
what is the benefit of using repository as a value? is it only to allow multiple directories to be scanned? because if we set
input path to repo root, it takes way more time to execute. all solution files are unnecessarily scanned and skipped, until template files are found.
Is it a valid use to have it like

  inputType: "repository"
  inputPath: "$(projectDirectory)/devops/infrastructure/bicep/*.bicep"

where only inputType is different (inputPath -> repository) and the path itself points to the exact files we want to target (and not the repository)?

also, unrelated, but in logs we see warnings for every .bicep file, like:
##[warning]Target object 'Project/devops/infrastructure/bicep/function-app.bicep' has not been processed because no matching rules were found.
In a way it makes sense, rules are for ARM templates that are decompiled from bicep (for which they find and run rules), but it's still misleading to say that this template was not processed, no?

from psrule-pipelines.

@dkaubar That's great. Thanks for the feedback.

When inputType: inputPath is used a limited number of file formats are loaded from disk a read as objects. Supported formats are listed under the Input.Format.

For example, a JSON file:

[
  {
    "name": "object1"
  },
  {
    "name": "object2"
  }
]

Bicep and Azure template formats are a little tricky, they have parameters, variables, functions, loops, conditions, etc within their structure. Reading the objects is not a good indication of what resources would be deployed to Azure, or what their final state would be.

The repository option discovers the files and passed them through some additional functions to expand the Azure resources from the Bicep/ Template code.

With inputPath: "$(projectDirectory)/devops/infrastructure/bicep/*.bicep" only the files matching the path would be scanned regardless of if inputType set to inputPath or repository.

Additionally, with repository the Input.PathIgnore option can be set. See Configuring path exclusions and Input.PathIgnore.

In terms of the warning, yes that is expected. You are correct, the files are not being processed by any rule which is the reason for the warning. We could do better to hide this by default, however you can disable the warning by setting the Execution.NotProcessedWarning option to false.

I hope that helps.

from psrule-pipelines.