Support authorization_scopes and request_models on routes #56
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Set
authorization_scopes
andrequest_models
on the created route resource when specified inintegrations
.Motivation and Context
I'm experimenting with converting a toy SAM template to Terraform using this module, and found that i couldn't proceed because the module doesn't handle
authorization_scopes
.Both this attribute and
request_models
are commented out in the source because the previous dev didn't know what their structure was. Per the provider source,authorization_scopes
is aset(string)
andrequest_models
is amap(string)
.I'm not sure it really matters, though, since
integrations
is amap(any)
— if i understand correctly, that requires you to usejsonencode()
or similar on non-scalar values. That's how some of the integration resource's attributes are currently handled, anyway.I think the
try()
method being used here would allowintegrations
to be changed to a fully typedmap(object(...))
whilst retaining backwards compatibility, but i haven't tried making that change myself. (I'm not familiar enough with Terraform or this project to know if it's even desirable.)Breaking Changes
This shouldn't affect backwards compatibility.
How Has This Been Tested?
examples/*
projectsI tested this by sourcing my branch of the repo as a local module, adding an integration like the following, and deploying to AWS.
This resulted in the route being associated with the authoriser and having the correct authorisation scopes specified.
If there's further testing i should do, please let me know how; i'm still pretty new to both Terraform and AWS.