chore(cxapi): plugin context provider limited by cx schema#18709
chore(cxapi): plugin context provider limited by cx schema#18709mergify[bot] merged 4 commits intomasterfrom
Conversation
During internal trialing of context provider plugins, we discovered that
the JSON schema validation of the Cloud Assembly is throwing soot into
our food: any properties we add aren't exactly those of another context
provider, and therefore not allowed.
Add a new branch of the context provider schema, a `PluginContextQuery`,
which allows any set of properties. The actual plugin name is now merely
a property passed to the "plugin" context provider.
When the handler is registered or the query is handled, we combine the
key in the lookup table with the actual provider name as such:
`plugin:${pluginName}`. This is an implementation detail of the CLI, and
not part of the contract (can be changed easily whenver necessary).
|
|
| @@ -1 +1 @@ | |||
| {"version":"16.0.0"} No newline at end of file | |||
| {"version":"17.0.0"} No newline at end of file | |||
There was a problem hiding this comment.
Curious - do we bump the major version of the schema with every change? Is this change a breaking change? (If this is a silly question, please explain why. 😄 I don't fully understand the contract here. Is the API only used by us?)
There was a problem hiding this comment.
We do bump the MV of the schema with every change. Every change is indeed potentially breaking (at any point the framework could be requesting services from the CLI that the CLI may not know how to provide--i.e., CLI needs an update to match).
It's a bit onerous to do this though, and you're right that in this particular case it's probably not necessary. This was just forced upon me by the tools we're using. Will revert the version.
corymhall
left a comment
There was a problem hiding this comment.
I did not know we had context provider plugins!
| /** | ||
| * Arbitrary other arguments for the plugin | ||
| */ | ||
| [key: string]: any; |
There was a problem hiding this comment.
readonly pluginArguments?: [key: string]: any;Can we change this to something like this?
There was a problem hiding this comment.
We could, but this feels simpler (requires fewer code changes, too).
It's only for internal use. |
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
* origin/master: (27 commits) chore(eks): deprecate older versions of EKS (aws#18842) fix(tooling): update vscode devcontainer image (aws#18455) chore: npm-check-updates && yarn upgrade (aws#18832) chore(docs): Fix broken md links (aws#18384) chore(lambda-layer-awscli): install awscli with pip and requirements.txt (aws#18800) fix(aws-appsync): Strip unsupported characters from Lambda DataSource (aws#18765) feat(cfnspec): cloudformation spec v55.0.0 (aws#18827) docs(cfnspec): update CloudFormation documentation (aws#18826) chore(cxapi): plugin context provider limited by cx schema (aws#18709) feat(iotevents): add grant method to Input class (aws#18617) chore(cx-api): break circular dependencies (aws#18767) docs(core): clarify that `addOverride` does not change property casing (aws#18687) feat(s3-deployment): deploy data with deploy-time values (aws#18659) docs(cfnspec): update CloudFormation documentation (aws#18808) feat(cli): `cdk diff` works for Nested Stacks (aws#18207) docs(cfnspec): update CloudFormation documentation (aws#18783) chore(lambda-layer-awscli): add update mechanism for AWS CLI (aws#18780) chore(release): 1.143.0 feat(fsx): add support for FSx Lustre Persistent_2 deployment type (aws#18626) feat(amplify): support performance mode in Branch (aws#18598) ...
During internal trialing of context provider plugins, we discovered that
the JSON schema validation of the Cloud Assembly is throwing soot into
our food: any properties we add aren't exactly those of another context
provider, and therefore not allowed.
Add a new branch of the context provider schema, a `PluginContextQuery`,
which allows any set of properties. The actual plugin name is now merely
a property passed to the "plugin" context provider.
When the handler is registered or the query is handled, we combine the
key in the lookup table with the actual provider name as such:
`plugin:${pluginName}`. This is an implementation detail of the CLI, and
not part of the contract (can be changed easily whenver necessary).
----
*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
During internal trialing of context provider plugins, we discovered that
the JSON schema validation of the Cloud Assembly is throwing soot into
our food: any properties we add aren't exactly those of another context
provider, and therefore not allowed.
Add a new branch of the context provider schema, a
PluginContextQuery,which allows any set of properties. The actual plugin name is now merely
a property passed to the "plugin" context provider.
When the handler is registered or the query is handled, we combine the
key in the lookup table with the actual provider name as such:
plugin:${pluginName}. This is an implementation detail of the CLI, andnot part of the contract (can be changed easily whenver necessary).
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license