[BUG] Unable to use input.ignoreUnchangedPath in Azure DevOps

[ReneRebsdorf]

Description of the issue

Hi,

I am leaning towards this being a fault at my end, more-so than a general bug in the product, but given my attempts to follow previous instructions from @BernieWhite as well as following the docs, I am curious if there is evidence that using powershell to run PSRule works with git diff in Azure DevOps?

It works when running locally.

I have set the following in ps-rule.yaml:

input:
  ignoreUnchangedPath: true
repository:
  baseRef: main

We use Azure DevOps with the following stage:

        steps:
          - checkout: self
            fetchDepth: 0
          - script: |
              cd governance
              git checkout ${$(Build.SourceBranch)#refs/heads/}
            displayName: Prepare git
          - checkout: common
          - task: PowerShell@2
            name: PSRule_pre_deployment
            inputs:
              targetType: filePath
              filePath: $(Build.SourcesDirectory)/governance/tests/PSRulePreDeployment.ps1
              pwsh: true
              errorActionPreference: stop
              failOnStderr: true
            continueOnError: false

• "governance" being our repo name in the above that we want to test
• "common" is a library repo, which contains custom ps rules such as naming convention
• PSRulePreDeployment.ps1 contains some logic to ensure PSRule modules and deps are installed from PSGallery, sets the directory for where to run, and runs Assert-PSRule with -InputPath as the root of the repo to test, -Option points to the ps-rule.yml where the above code snippet is taken from, and -Path points to the folder containing the custom rules in the "common" repo.

I have also tried setting the "PSRULE_INPUT_IGNOREUNCHANGEDPATH" env var in the PowerShell@2 task, it did not affect the outcome.
I use the cd and git checkout commands to overcome the detached head, which I get despite having fetchDepth set to 0, and the PSRule docs states detached heads are not supported

My questions:

• Could it be confirmed that "ignore unchanged path" works for how Azure DevOps handles repos?
• If it works in your end, can you spot what I am doingwrong?
• If it does not work; perhaps using git rev-parse internally in PSRule would be an option to overcome this, as method to getting changes between branches, which works in detached head?

Error messages

N/A - but all files are being scanned.

Reproduction

Described under "description of issue"

Version of PSRule

2.9.0

How are you running PSRule

Azure DevOps triggering a PowerShell task

Additional context

No response

[BernieWhite]

Thanks for reporting the issue @ReneRebsdorf. It should, but let me double check these details and get back to you.

[BernieWhite]

Hi @ReneRebsdorf, with the standard checkout: self and fetchDepth: 0 try to set your repository.BaseRef option in ps-rule.yaml to be origin/main instead of just main. Because main is not local ref by default, so it's not available for comparison, but the remote ref should be.

You might encounter #1465.

---

Also, a specific with Bicep is that for modules you may test though a test file like .tests/main.test.bicep.

If the main.test.bicep file does not change then it won't be captured in the change file set. But if the module file main.bicep changed then you still want to test it.

You can use a convention such as the following to explode the change file set. (can't reduce it). Happy to explain this further if the comment doesn't make sense.

For example .ps-rule/Explode.Rule.ps1

Export-PSRuleConvention 'AddModuleFiles' -Initialize {
    Write-Host "Initializing AddModuleFiles convention"

    # Get the change file set for any bicep files.
    foreach ($inputFile in $PSRule.Repository.GetChangedFiles().WithExtension('.bicep')) {
        # Calculate the module path, modules are expected to be under modules/<moduleName>/v<version>
        # Tests are under modules/<moduleName>/v<version>/.tests/main.tests.bicep
        $modulePath = $inputFile.AsFileInfo().Directory;
        while (!$modulePath.Name.StartsWith('v')) {
            $modulePath = $modulePath.Parent;
        }
        $moduleVersion = $modulePath.Name;
        $moduleName = $modulePath.Parent.Name;

        # Add tests
        Write-Host "Adding module tests for $moduleName/$moduleVersion";

        if (!(Test-Path "$($modulePath.FullName)/.tests/main.tests.bicep")) {
            Write-Warning "No tests found for $moduleName/$moduleVersion";
        }
        else {
            $PSRule.Input.Add($modulePath.FullName + "/.tests/main.tests.bicep");
        }

        # Add matching docs
        $PSRule.Input.Add("docs/modules/$moduleName-$moduleVersion/**");
    }
}

For example ps-rule.yaml

convention:
  include:
    - AddModuleFiles

---

In terms of changing the git command line, if that doesn't work for your environment, additional options or ability to customize the method can be added in a future enhancement for v3.x.

If I remember correctly the reason for using diff is it provides a good comparison point for files that are also not committed. Which is relevant if files are dropped in or for local editing.

[ReneRebsdorf]

Thank you for the answer, I tested this over the weekend, and pointing to origin/main works perfectly.

We do not use tests as you described, so the problem is not applicable to us, your explanation and workaround (with convention) was perfectly understandable.

Regarding pathIgnore, our input object looks like this:

input:
  # Required for parameter file expansion
  format: File
  pathIgnore:
    # Only process parameter files
    - "*"
    - "!baseline/**/azureDeploy.parameters.json"
    - "!tenants/**/hierarchy/**/azureDeploy.parameters.json"

which is used in tandem with:

configuration:
  AZURE_PARAMETER_FILE_EXPANSION: true
  AZURE_PARAMETER_FILE_METADATA_LINK: true

  # Disable expansion of Azure Bicep files as bicep files are discovered via the parameter files
  AZURE_BICEP_FILE_EXPANSION: false
  AZURE_BICEP_FILE_EXPANSION_TIMEOUT: 60

The tests seems to work fine and are not impacted by #1465 - but if I run across problems we might decide to wait with this until #1465 is resolved.

Closing this bug report, I recommend the docs are updated to mention using origin/main over main :-)

[ReneRebsdorf]

@BernieWhite are you aware of the same problem as what you are describing with the "convention-fix" when using parameter expansion?

e.g. if we have azureDeploy.json and azureDeploy.parameters.json but only modify the azureDeploy.json file? If we modify the parameters in azureDeploy.json from say a string to an int, but keep parsing a string in azureDeploy.parameters.json this is correctly discovered if not using ignoreUnchangedPath, but with ignoreUnchangedPath this is not discovered.

I assumed that based on metadata.template in the parameter files, that based any changes to those templates would be tested for too, is this perhaps the case for psrule v3, if not would you like me to raise a separate bug for this?

[BernieWhite]

@ReneRebsdorf Yes, that could happen. If you modify the azureDeploy.json file but not azureDeploy.parameters.json then as far as git is concerned, there was no change to the azureDeploy.parameters.json file.

In this case, it's not really a PSRule bug since the purpose it to improve performance and relevance by only processing files that have changed. That problem is that can be too simplistic when a deployment and "what would be deployed to Azure" is incorporated over multiple files.

The convention can be adapted to your environment to increase the change set inspected by PSRule based on the structure and naming standards of the repo. Providing a generic solution is tricky because understanding the relationship between two deployment files often has its own nuances between organizations so it hasn't been developed so far.

---

Could we do it better and expand documentation examples? absolutely. Open to thoughts from your own experience implementing this on how this can be improved.

I've raised the following issues for follow up and to continue the discussion:

• [BUG] Fix branch ref for working with changes files only examples #2777
• [FEATURE] Improve documentation for working with change files only #2778