-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
New Resource: azurerm_api_management_policy #3145
Conversation
porting in the changes from #3145 into the APIM resource
porting in the changes from #3145 into the APIM resource
porting in the changes from #3145 into the APIM resource
porting in the changes from #3145 into the APIM resource
porting in the changes from #3145 into the APIM resource
hey @JunyiYi Thanks for this PR :) Taking a look into this it appears it's only possible to specify one Policy for the API Management Service (since there's no unique name per top-level policy) - as such rather than making this it's own resource I believe we should roll this up into the parent API Management Resource. I hope you don't mind, but I'm going to pull some of the changes you've made here out into a new PR which merges this into the parent Thanks! |
porting in the changes from #3145 into the APIM resource
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks! |
In this PR, I introduced the global API Management Policy.
Since the backend service will always re-format the XML content (for example, change line endings to
\r\n
, change quotation marks, using\t
to indent) of the policy; I implement a XML ignore diff function.I also thought of wrapping all the policies into an abstracted structure in Terraform. However that is not doable due to advanced recursive control flows.
xml_link
requires a public-accessible HTTP endpoint of an valid configuration XML file. That's why I have not included any acceptance tests. Maybe we can add some files inexamples
folder and add the test cases later?