Ability to configure which subscriptions to track

[Xitric]

Describe the solution you'd like

In our Azure tenant, we have different application landing zone subscriptions for production, staging, and testing of our primary product. In accordance with #747, we wish to use separate AzOps repositories to track deployments to each of these environments. At the same time, we make extensive use of Bicep modules from a private container registry, which is placed in a separate platform subscription:

• root (mg)
  • (mg)
    • platform (mg)
      • management (mg)
        • management (sub)
          • container registry
    • landing zones (mg)
      • online (mg)
        • prod (sub)
        • stage (sub)
        • test (sub)

The service principal we use for deploying resources to prod (sub) has the following permissions:

• Owner on prod (sub)
• AcrPull on the container registry in management (sub)

As a result, when running the pull pipeline, AzOps tracks both the subscriptions prod and management. It isn't actually able to list role assignments, policies, resource groups, or anything else inside management (sub), but it does generate a directory along with a microsoft.subscription_subscriptions-<sub-id>.json file.

We would really like to be able to configure which subscription(s) to track via AzOps - something like Core.SubscriptionsToInclude or similar.

[Xitric]

This feature request is no longer strictly needed for our team. Courtesy of #424, we decided that it would be appropriate to use .gitignore as a means of controlling which subscriptions we track via AzOps.

We simply add the subscriptions that we wish to exclude to the .gitignore. That way, while the subscription-specific files are generated by the pull pipeline, they never make it into the git repository itself via the pull request. The end result is effectively the same as not pulling the files for the subscription in the first place. Excluding the subscription via AzOps itself would at most be a minor performance improvement that we at least do not need.

For instance, our .gitignore would look something like this:

# Subscriptions to exclude
/root/my subscription (00000000-0000-0000-0000-000000000000)/**
/root/my other subscription (00000000-0000-0000-0000-000000000001)/**

@Jefajers We can go ahead and close this issue, or add a section to the documentation in case this could be helpful for others. It was not immediately obvious to us, but now that we have started using the .gitignore with AzOps it seems so natural!

[jsandquist]

We also use .gitignore - quite extensively - where built-in settings don't match our specific needs. As long as we don't discard too many files it works perfectly fine with an acceptable run time for the pull pipeline.