docs: add links to CloudFormation documentation to READMEs#17696
docs: add links to CloudFormation documentation to READMEs#17696mergify[bot] merged 9 commits intomasterfrom
Conversation
Currently, the documentation of our CFN-only libraries leaves a lot to be desired, which is confusing users. Update the READMEs to make it very clear that we don't have anything for them, and point them to the right location for getting documentation.
| import * as aws_amazonmq from '@aws-cdk/aws-amazonmq'; | ||
| ``` | ||
|
|
||
| There are no hand-written ([L2](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_lib)) constructs for this service yet. |
There was a problem hiding this comment.
How about adding a block here such as
<!-- BEGIN CFNONLY DISCLAIMER -->
...
<!-- END CFNONLY DISCLAIMER -->
and then checking with pkglint that this only exists for packages whose maturity > cfn-only.
There was a problem hiding this comment.
What is the advantage of doing this? I'd prefer not to add more pkglint checks unless absolutely necessary.
There was a problem hiding this comment.
Contributors missing to remove this when adding the first L2 to a package. It's non-obvious.
It'll happen more often than you think.
| @@ -0,0 +1,31 @@ | |||
| // Helper script to regen all CFN-only library readmes from the template. | |||
There was a problem hiding this comment.
How about just run this every time during cfnspec bump?
Otherwise, no one is going to know about this besides you.
There was a problem hiding this comment.
I think this comment is trying to make sure new modules are being created with the right READMEs.
That already happens, the READMEs that are being created for new modules pass through the same code path.
There was a problem hiding this comment.
Isn't this script also meant to be run when the "template" changes? Re-gen on all L1 modules?
Running this each time would mean that any missed corrections will be caught (at least during bump).
|
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). |
Currently, the documentation of our CFN-only libraries leaves a lot to be desired, which is confusing users. Update the READMEs to make it very clear that we don't have anything for them, and point them to the right location for getting documentation. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Our build pipeline is currently failing because `cfnspec` (which is a public package) takes a runtime dependency on `pkglint` (which is a private package). This was introduced in #17696. To resolve this, we moved the functionality that generates new L1 library code from `lib/` to `build-tools/` since it's only needed in CDK build context (technically this is breaking public API, but we could not see any use case for external users to generate L1 modules in CDK-repository format). ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Our build pipeline is currently failing because `cfnspec` (which is a public package) takes a runtime dependency on `pkglint` (which is a private package). This was introduced in aws#17696. To resolve this, we moved the functionality that generates new L1 library code from `lib/` to `build-tools/` since it's only needed in CDK build context (technically this is breaking public API, but we could not see any use case for external users to generate L1 modules in CDK-repository format). ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Currently, the documentation of our CFN-only libraries leaves a lot to be desired, which is confusing users. Update the READMEs to make it very clear that we don't have anything for them, and point them to the right location for getting documentation. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Our build pipeline is currently failing because `cfnspec` (which is a public package) takes a runtime dependency on `pkglint` (which is a private package). This was introduced in aws#17696. To resolve this, we moved the functionality that generates new L1 library code from `lib/` to `build-tools/` since it's only needed in CDK build context (technically this is breaking public API, but we could not see any use case for external users to generate L1 modules in CDK-repository format). ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Currently, the documentation of our CFN-only libraries leaves a lot to
be desired, which is confusing users.
Update the READMEs to make it very clear that we don't have anything for
them, and point them to the right location for getting documentation.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license