Skip to content
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

refactor: move list of stateful resource types to data file #1897

Merged

Conversation

rix0rrr
Copy link
Contributor

@rix0rrr rix0rrr commented Feb 10, 2021

aws/aws-cdk#12920

The CDK would like to use the same data that cfn-lint is using to
help our code generation.

This change moves the list of stateful resource types to a JSON file,
which is easier to parse for the CDK build process than a Python source
file. This will help keep the source of truth in sync between the
two projects.

This is not supposed to be the be-all-and-end-all solution of
integration between the two projects. I'm aware it's quite ad-hoc;
but let's try something low-friction and see how it goes?


By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

The CDK would like to use the same data that cfn-lint is using to
help our code generation.

This change moves the list of stateful resource types to a JSON file,
which is easier to parse for the CDK build process than a Python source
file. This will help keep the source of truth in sync between the
two projects.

This is not supposed to be the be-all-and-end-all solution of
integration between the two projects. I'm aware it's quite ad-hoc;
but let's try something low-friction and see how it goes?
@kddejong kddejong merged commit e12a293 into aws-cloudformation:master Feb 10, 2021
direvus pushed a commit to direvus/cfn-python-lint that referenced this pull request Apr 12, 2021
…dformation#1897)

The CDK would like to use the same data that cfn-lint is using to
help our code generation.

This change moves the list of stateful resource types to a JSON file,
which is easier to parse for the CDK build process than a Python source
file. This will help keep the source of truth in sync between the
two projects.

This is not supposed to be the be-all-and-end-all solution of
integration between the two projects. I'm aware it's quite ad-hoc;
but let's try something low-friction and see how it goes?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants