-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
chore(cxapi): plugin context provider limited by cx schema #18709
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).
{"version":"17.0.0"} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
readonly pluginArguments?: [key: string]: any;
Can we change this to something like this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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