Split out from the v2 RFC (#378 thread, raised by @tuukkafc).
Problem
Tags defined at the Serverless provider level are not applied to the AppSync API. Users
expect provider tags to propagate to resources the way they do for other resources, but the
plugin only uses tags defined under appSync.tags.
Current state (v2)
Api.getTagsConfig() reads only this.config.tags (the appSync.tags block) and there is
no reference to provider.tags (or provider.stackTags) anywhere in the plugin. So
provider-level tags are dropped for the AppSync API.
Proposal
Merge provider.tags with appSync.tags when building the API's Tags, with appSync.tags
taking precedence on key conflicts. Small, surgical change in getTagsConfig().
Scope notes
AWS::AppSync::GraphQLApi supports Tags; AWS::AppSync::DataSource and
AWS::AppSync::Resolver do not, so the practical scope is the API resource (and
potentially the log group, which is a separate AWS::Logs::LogGroup).
- Worth deciding whether to also fold in
provider.stackTags.
Split out from the v2 RFC (#378 thread, raised by @tuukkafc).
Problem
Tags defined at the Serverless
providerlevel are not applied to the AppSync API. Usersexpect provider tags to propagate to resources the way they do for other resources, but the
plugin only uses tags defined under
appSync.tags.Current state (v2)
Api.getTagsConfig()reads onlythis.config.tags(theappSync.tagsblock) and there isno reference to
provider.tags(orprovider.stackTags) anywhere in the plugin. Soprovider-level tags are dropped for the AppSync API.
Proposal
Merge
provider.tagswithappSync.tagswhen building the API'sTags, withappSync.tagstaking precedence on key conflicts. Small, surgical change in
getTagsConfig().Scope notes
AWS::AppSync::GraphQLApisupportsTags;AWS::AppSync::DataSourceandAWS::AppSync::Resolverdo not, so the practical scope is the API resource (andpotentially the log group, which is a separate
AWS::Logs::LogGroup).provider.stackTags.