[FEATURE/DISCUSSION] - How to deal with Azure Deployment Stacks outputs and PSRule

[riosengineer]

Hey Bernie.

I'm heavily using ADS now and with that, I am usually pulling in the existing resource stack to downstream templates to get their output values dynamically.

My issue with this for PSRule is we require all values present before the template can expand and run the ruleset.

I am wondering if there's any idea or neat way to get around this scenario as I see it becoming more popular over time. I don't really want to make my existing resource optional in my production template, and alternatives seem tedious and repetitive. (like copying my main template to my test file just to conditional / mock)

// hub stack reference
resource resHubStack 'Microsoft.Resources/deploymentStacks@2024-03-01' existing = {
  name: parHubStackName
  scope: subscription(parHubSubscriptionId)
}
...

module modVirtualNetwork 'br/public:avm/res/network/virtual-network:0.7.1' = {
  params: {
....
    peerings: [
      {
        remoteVirtualNetworkResourceId: resHubStack.properties.outputs.outHubVirtualNetworkId.value

My test file for PSRule doesn't have this value, so it fails.

[github-actions]

Thanks for raising your first issue, the team appreciates the time you have taken 😉

[BernieWhite]

Hi @riosengineer, thanks for the question. Currently there wouldn't be an easy way around it because the output of a existing reference to a deploymentStack doesn't have a predefined shape or expected set of properties and values. Which differs if PSRule can see a clear linkable code to the resource. PSRule does a fair bit to mock these values but when code deeper down consuming the values starts to format or manipulate the values it can get messy when the actual value is unknown.

However that said, happy to work toward a solution of which there might be a few. I'd need to have a better understanding on how you are using existing references. I see the example you provided above appears to be a shared potentially VNET hub or something similar which make sense.

Are you are able to provide more detail, such as:

• Is the code the referenced deployment stack in the same repository?
• Is case where you would use an existing deployment stack confined or mostly for shared infrastructure components e.g. networking, monitoring, security, etc...
• Is the deployment stack already deployed to Azure? Or does it potentially not exist yet at the same time you are building / testing this code.
• Any other specifics you can share from your experience or the experience of the customers you work with.

Also if you already have an ideal solution in mind, let me know.

[riosengineer]

• Is the code the referenced deployment stack in the same repository?

Usually yes, but not always. For simplicity, in this scenario I am testing and others it is in the same repo for now.

• Is case where you would use an existing deployment stack confined or mostly for shared infrastructure components e.g. networking, monitoring, security, etc...

Yeah, but also for micro deployments. E.g. Landing Zone App1 has a networking, monitoring, core stack (separated) and chaining downstream values from each stack using resource existing.

• Is the deployment stack already deployed to Azure? Or does it potentially not exist yet at the same time you are building / testing this code.

It's deployed, so should always exist in this scenario.

• Any other specifics you can share from your experience or the experience of the customers you work with.

Nothing extra currently.

As for a solution, I am not too sure. An idea I sort of was moving towards was potentially something in the ps-rule.yaml to enable such a feature idea like:

  AZURE_MOCK_EXISTING_RESOURCES_ENABLED: true
  AZURE_MOCK_EXISTING_RESOURCES_PATH: 
    - '.psrule/mocks/*.yaml'

Then maybe some way to define the values in a way that the psrule engine can match them? Similar to the custom rules schema?

#
# Mock existing deployment stacks
#

apiVersion: github.com/microsoft/PSRule.Rules.Azure/v1
kind: MockExistingResources
metadata:
  name: deployment-stacks
  description: Mock outputs for existing deployment stacks

spec:
  resources:
    # Hub deployment stack
    - resourceType: Microsoft.Resources/deploymentStacks
      scope: subscription
      subscriptionId: '00000000-0000-0000-0000-000000000000'
      name: az-stack-hub
      location: uksouth
      outputs:
          outHubVirtualNetworkId:
            type: String
            value: /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-hub/providers/Microsoft.Network/virtualNetworks/vnet-hub

Then in theory, at least, PSRule could match the:

existing resource by the name:, scope:, type: and anything else relevant to ensure it hits the correct mock (in case of many).

Just an idea, really haven't done this before and tried to follow the projects schema/structure with the idea.

[BernieWhite]

@riosengineer Seems fine, but I think it might get a little tedious if you had to craft these each time manually across multiple repos?

An option would be to initialize this by exporting these from Azure. The files could be crafted manually if access to Azure is not available/ acceptable for some reason. Or potentially generated from the original code and then imported into the repo.

[BernieWhite]

@riosengineer Additionally, a question would be for your uses cases is it for testing deployments, or for unit tests that are used for validating reusable modules?

[riosengineer]

@riosengineer Additionally, a question would be for your uses cases is it for testing deployments, or for unit tests that are used for validating reusable modules?

Yeah so I would love to use the same test file to not only unit test with the PSRule engine but then be able to use this to test complete deployments. That's really my ultimate goal.

[riosengineer]

@riosengineer Seems fine, but I think it might get a little tedious if you had to craft these each time manually across multiple repos?

An option would be to initialize this by exporting these from Azure. The files could be crafted manually if access to Azure is not available/ acceptable for some reason. Or potentially generated from the original code and then imported into the repo.

Yeah this would be ideal. I am likely to have a lot of existing stacks overtime. As you say, if I cannot mock the values myself and it just be able to export them to make it easier that would be amazing. Please feel free to ping me if you need any testing if a feature like this ever comes into fruition on the roadmap. Happy to help out!