Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explain reasoning for duplicate content in the structure #74184

Closed
JohnLBevan opened this issue Apr 22, 2021 · 3 comments
Closed

Explain reasoning for duplicate content in the structure #74184

JohnLBevan opened this issue Apr 22, 2021 · 3 comments

Comments

@JohnLBevan
Copy link
Contributor

The current suggested structure includes policy.json, policy.parameters.json, and policy.rules.json.
The policy file includes sections for parameters and rules; and the content of these in all examples I've seen typically duplicate exactly what's in the .parameters and .rules files.

To me it would make sense to only maintain these definitions in one place; then if a different format were needed use scripts to generate these other files; but to avoid including that generated content under source control (i.e. only include the single definition file and the scripts to perform the conversion).

I couldn't see anything in the document explaining why we may wish to have this duplication / if some of the content is expected to be generated, but included in the .gitignore file to prevent it from being tracked in the repo itself. Please could something be added to clarify this?


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

@DCtheGeek
Copy link
Contributor

@JohnLBevan Thanks for the question! The structure is partially to help with some of the SDK functions that take those components as a standalone file. For example, in Azure CLI the command for creating a policy assignment, az policy assignment create, uses a params (or p) parameter that expects a JSON string or path of just the parameter node. While you could add extra steps in your pipeline to shard the "core" file that has this information, the team felt it was a cleaner path to have each file used as part of the source. I'll ping one of the PMs to see if this approach still holds.

#assign:DCtheGeek
#label;"product-question"
#label:"triaged"
#label:"assigned-to-author"
#label:"in-progress"

@DCtheGeek
Copy link
Contributor

#label:"product-question"

@DCtheGeek
Copy link
Contributor

Confirmed that this approach still stands and is recommended. I'm going to close this issue now. Feel free to open a new Issue for any Docs issues you see. Thanks!

#please-close

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants