Merge branch 'main' into emr-policy-tag

CONTRIBUTING.md

@@ -14,6 +14,10 @@ This document describes how to set up a development environment and submit your
 let us know if it's not up-to-date (even better, submit a PR with your  corrections ;-)).
 
 - [Where To Contribute](#where-to-contribute)
+  - [Demonstrating Value](#demonstrating-value)
+  - [Publishing Your Own Package](#publishing-your-own-package)
+    - [Trust and Third Party Packages](#trust-and-third-party-packages)
+    - [Third Party Package Administration](#third-party-package-administration)
 - [Getting Started](#getting-started)
   - [Local setup](#setup)
   - [Dev Container](#dev-container)
@@ -99,7 +103,7 @@ Here are some things we look at when evaluating a contribution:
 1. Signal - Is there a github issue, or possibly multiple related ones, that the contribution addresses. Do the issues have a lot of engagement, such as comments, +1 reactions, etc that indicate that many users are affected by it?
 1. Size - Is the contribution limited to a relatively self-contained surface area? Is it broken up into the smallest possible unit of functionality that makes sense?
 1. Priority - Does the contribution address an issue in, or add a new feature of, a service that has a high priority for coverage? These are generally core services most commonly used on AWS such as IAM, EC2, Lambda, and ECS.
-1. Quality - Does the contribution take into account all of the guidance provided in our documentation regarding design patterns, test coverage, and best practices as it relates to code within the aws-cdk repository? Does it also make an effort to follow patterns commonly used within the aws-cdk repository and not deviate unecessarily from these conventions?
+1. Quality - Does the contribution take into account all of the guidance provided in our documentation regarding [design patterns](./docs/DESIGN_GUIDELINES.md), test coverage, and best practices as it relates to code within the aws-cdk repository? Does it also make an effort to follow patterns commonly used within the aws-cdk repository and not deviate unecessarily from these conventions?
 1. Breaking Changes - Does the contribution introduce any risk for breaking existing users applications? Specifically, does it require any code changes or can it trigger any resource replacement in cloudformation that would result in downtime?
 
 ### Demonstrating Value
@@ -362,16 +366,15 @@ much more likely to give a PR for those issues prompt attention.
 
 ### Step 2: Design
 
-In some cases, it is useful to seek feedback by iterating on a design document. This is useful
-when you plan a big change or feature, or you want advice on what would be the best path forward.
+In some cases, it is useful to seek feedback by iterating on a design document. This is useful when you plan a big change or feature, or you want advice on what would be the best path forward.
 
-In many cases, the GitHub issue is sufficient for such discussions, and can be
-sufficient to get clarity on what you plan to do. If the changes are
-significant or intrusive to the existing CDK experience, and especially for a
-brand new L2 construct implementation, please write an RFC in our [RFC
-repository](https://github.com/aws/aws-cdk-rfcs) before jumping into the code
-base. L2 construct implementation pull requests will not be reviewed without
-linking an approved RFC.
+In many cases, the comments section of the relevant Github issue is sufficent for such discussion, and can be a good place to socialize and get feedback on what you plan to do. If the changes are significant in scope, require a longer form medium to communicate, or you just want to ensure that the core team agrees with your planned implementation before you submit it for review to avoid wasted work, there are a few different strategies you can pursue.
+
+1. README driven development - This is the core team's preferred method for reviewing new APIs. Submit a draft PR with updates to the README for the package that you intend to change that clearly describes how the functionality will be used. For new L2s, include usage examples that cover common use cases and showcase the features of the API you're designing. The most important thing to consider for any feature is the public API and this will help to give a clear picture of what changes users can expect.
+1. Write an [RFC](aws/aws-cdk-rfcs) - This is a process for discussing new functionality that is large in scope, may incur breaking changes, or may otherwise warrant discussion from multiple stakeholders on the core team or within the community. Spefically, it is a good place to discuss new features in the core CDK framework or the CLI that are unable to be decoupled from the core cdk codebase.
+1. Publish a package - A separate package is the best place to demonstrate the value of new functionality that you believe should be included within the CDK core libraries. It not only illustrates a complete solution with it's entire API surface area available to review, it also proves that your design works! When publishing a package with the goal for eventual inclusion within aws-cdk-lib, make sure to follow our [design guidelines](./docs/DESIGN_GUIDELINES.md) wherever relevant.
+
+Performing any of the above processes helps us to ensure that expectations are clearly set before a contribution is made. We want to ensure that everyone is able to contribute to the CDK ecosystem effectively. If you make a contribution that is ultimately not merged by into aws-cdk-lib, but you believe it should be, we encourage you to keep pursuing it. The scope of the core framework is intentionally limited to ensure that we can effectively maintain it's surface area and ensure code quality and reliablity over the long term. However, new patterns may emerge in the ecosystem that clearly provide better solutions than those currently in aws-cdk-lib. If your solutions gains popularity within the community, and you want us to re-evaluate it's inclusion, reach out to us on cdk.dev or create a github issue with a feature request and references to your package. See [demonstrating value](#demonstrating-value) for more information. 
 
 ### Step 3: Work your Magic
 

docs/NEW_CONSTRUCTS_GUIDE.md

@@ -11,8 +11,9 @@ If you wish to create new L2 (or potentially L3) constructs, this guide can help
 Users of the aws-cdk can use constructs from a number of packages within their application. `aws-cdk-lib` and/or any of the other constructs vended from npm, maven, pypi, nuget, or GitHub (for go) that are publicly available are indexed and searchable on [Construct Hub](constructs.dev). Anyone can create and publish new constructs that will be indexed on Construct Hub using repositories and packages that they own. However, if you believe your constructs should be part of the core aws construct library, here are some guidelines that they must adhere to.
 
 1. They meet the definition of [L2 constructs](https://github.com/aws/aws-cdk/blob/e4fdb0217edd7ecccdd4cbc20de958e3ba1a2349/docs/DESIGN_GUIDELINES.md?plain=1#L139-L147)
-2. They follow the relevant [design guidelines](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)
-3. They can follow the aws-cdk's versioning and release strategy, ie: if they are to be vended in aws-cdk-lib they must be stable or instead be vended in an `-alpha` package.
+1. They follow the relevant [design guidelines](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)
+1. They can follow the aws-cdk's versioning and release strategy, ie: if they are to be vended in aws-cdk-lib they must be stable or instead be vended in an `-alpha` package.
+1. They provide constructs for a service that intersect with core aws usage patterns. For example, IAM, Lambda, EC2, DynamoDB, RDS, etc. 100% L2 coverage of every AWS service is not a goal of aws-cdk-lib.
 
 If your constructs do not meet these guidelines, see the [publishing your own package](#publishing-your-own-package) section of this guide, otherwise, you may choose to [publish your own package](#publishing-your-own-package) or [open a PR to aws-cdk-lib](#open-a-pr-to-aws-cdk-lib).
 
@@ -22,22 +23,21 @@ Whether you want to pursue inclusion of your new constructs in aws-cdk-lib or no
 
 To get started creating your own construct package, we recommend using [`projen`](https://github.com/projen/projen). Additionally you can follow [this guide](https://dev.to/aws-builders/a-beginner-s-guide-to-create-aws-cdk-construct-library-with-projen-5eh4) which will help you setup your repository, packages and tooling step by step.
 
-Once your constructs have been published for some time and you feel that the apis are stable and bugs have been identified, you can continue to distribute it as a separate package and/or attempt to add them to `aws-cdk-lib` via a PR
+Once your constructs have been published for some time and you feel that the apis are stable and bugs have been identified, you can continue to distribute it as a separate package and/or attempt to add them to `aws-cdk-lib` via a PR.
 
 ## Open a PR to `aws-cdk-lib`
 
 You can [create a PR](https://github.com/aws/aws-cdk/compare) in the `aws/aws-cdk` repository with your constructs at any time if you believe they are ready for inclusion. Here are some cases where opening a PR directly without publishing your own package first is ideal.
 
 1. It is a small addition to a service that has had stable L2 constructs for some time
-2. The service usage is well known and the API is unlikely to change.
-3. The defaults provided by the L2 are well known best practice
+1. The service usage is well known and the API is unlikely to change.
+1. The defaults provided by the L2 are well known best practice
 
-If any of the above are true and your constructs adhere to [the relevant guidelines](#do-my-constructs-belong-in-aws-cdk-lib), we encourage you to follow the [contributing guide](../CONTRIBUTING.md) and create a new pull request. Since the bandwidth of the aws-cdk team is limited, reviews and iteration may take some time. Additionally pull requests for new constructs are more likely to be accepted if they have any of the following:
+If all of the above are true and your constructs adhere to [the relevant guidelines](#do-my-constructs-belong-in-aws-cdk-lib), we encourage you to follow the [contributing guide](../CONTRIBUTING.md) and create a new pull request. Specifically, see the section on within the [Design](../CONTRIBUTING.md#step-2-design) section. Since the bandwidth of the aws-cdk team is limited, reviews and iteration may take some time. Additionally pull requests for new constructs are more likely to be accepted if they have any of the following:
 
-1. An [RFC](https://github.com/aws/aws-cdk-rfcs) with detailed design that has been reviewed by a member of AWS
-2. An existing package with users who have used and tested the Constructs and provided feedback
-3. Strong documentation
-4. Good unit and integration test coverage
+1. An existing package with users who have used and tested the Constructs and provided feedback
+1. Strong documentation
+1. Good unit and integration test coverage
 
 ## New Construct Development lifecycle
 
@@ -47,16 +47,15 @@ Whether publishing your own package or making a PR against aws-cdk-lib immediate
 
 ### Self Publishing
 1. Publish: design, write, and publish your new constructs
-2. Iterate: respond to issues from users, fix bugs, optimize usage patterns and gain consensus
-3. Stabilize: settle on the api
-
+1. Iterate: respond to issues from users, fix bugs, optimize usage patterns and gain consensus
+1. Stabilize: settle on the api
 *Optionally*
-4. Upstream: open a PR to aws-cdk-lib to include if still relevant
+1. Upstream: open a PR to aws-cdk-lib to include if still relevant
 
 ### Alpha CDK Package
-1. Design: create an [rfc](http://github.com/aws/aws-cdk-rfcs), socialize, and gain consensus
-2. Implement: write the construct as designed and create a new pull requests
-3. Iterate: respond to feedback from pull request reviewers on the aws-cdk team
-4. Publish: publish your new constructs as an alpha module
-5. Iterate: respond to issues from users, fix bugs and optimize usage patterns
-6. Stabilize: settle on the api and create a new PR migrating all constructs stability to "stable"
+1. Design: create a draft PR with the new README detailing the API, socialize, and gain consensus
+1. Implement: write the construct as designed and create a new pull requests
+1. Iterate: respond to feedback from pull request reviewers on the aws-cdk team
+1. Publish: publish your new constructs as an alpha module
+1. Iterate: respond to issues from users, fix bugs and optimize usage patterns
+1. Stabilize: settle on the api and create a new PR migrating all constructs stability to "stable"

packages/@aws-cdk-testing/framework-integ/test/aws-stepfunctions-tasks/test/bedrock/integ.invoke-model.js.snapshot/aws-stepfunctions-tasks-bedrock-invoke-model-integ.template.json

@@ -0,0 +1,140 @@
+{
+ "Resources": {
+  "StateMachineRoleB840431D": {
+   "Type": "AWS::IAM::Role",
+   "Properties": {
+    "AssumeRolePolicyDocument": {
+     "Statement": [
+      {
+       "Action": "sts:AssumeRole",
+       "Effect": "Allow",
+       "Principal": {
+        "Service": "states.amazonaws.com"
+       }
+      }
+     ],
+     "Version": "2012-10-17"
+    }
+   }
+  },
+  "StateMachineRoleDefaultPolicyDF1E6607": {
+   "Type": "AWS::IAM::Policy",
+   "Properties": {
+    "PolicyDocument": {
+     "Statement": [
+      {
+       "Action": "bedrock:InvokeModel",
+       "Effect": "Allow",
+       "Resource": {
+        "Fn::Join": [
+         "",
+         [
+          "arn:",
+          {
+           "Ref": "AWS::Partition"
+          },
+          ":bedrock:",
+          {
+           "Ref": "AWS::Region"
+          },
+          "::foundation-model/amazon.titan-text-express-v1"
+         ]
+        ]
+       }
+      }
+     ],
+     "Version": "2012-10-17"
+    },
+    "PolicyName": "StateMachineRoleDefaultPolicyDF1E6607",
+    "Roles": [
+     {
+      "Ref": "StateMachineRoleB840431D"
+     }
+    ]
+   }
+  },
+  "StateMachine2E01A3A5": {
+   "Type": "AWS::StepFunctions::StateMachine",
+   "Properties": {
+    "DefinitionString": {
+     "Fn::Join": [
+      "",
+      [
+       "{\"StartAt\":\"Prompt1\",\"States\":{\"Prompt1\":{\"Next\":\"Prompt2\",\"Type\":\"Task\",\"ResultPath\":\"$\",\"ResultSelector\":{\"names.$\":\"$.Body.results[0].outputText\"},\"Resource\":\"arn:",
+       {
+        "Ref": "AWS::Partition"
+       },
+       ":states:::bedrock:invokeModel\",\"Parameters\":{\"ModelId\":\"arn:",
+       {
+        "Ref": "AWS::Partition"
+       },
+       ":bedrock:",
+       {
+        "Ref": "AWS::Region"
+       },
+       "::foundation-model/amazon.titan-text-express-v1\",\"Body\":{\"inputText\":\"Generate a list of five first names.\",\"textGenerationConfig\":{\"maxTokenCount\":100,\"temperature\":1}}}},\"Prompt2\":{\"End\":true,\"Type\":\"Task\",\"ResultPath\":\"$\",\"ResultSelector\":{\"names.$\":\"$.Body.results[0].outputText\"},\"Resource\":\"arn:",
+       {
+        "Ref": "AWS::Partition"
+       },
+       ":states:::bedrock:invokeModel\",\"Parameters\":{\"ModelId\":\"arn:",
+       {
+        "Ref": "AWS::Partition"
+       },
+       ":bedrock:",
+       {
+        "Ref": "AWS::Region"
+       },
+       "::foundation-model/amazon.titan-text-express-v1\",\"Body\":{\"inputText.$\":\"States.Format('Alphabetize this list of first names:\\n{}', $.names)\",\"textGenerationConfig\":{\"maxTokenCount\":100,\"temperature\":1}}}}},\"TimeoutSeconds\":30}"
+      ]
+     ]
+    },
+    "RoleArn": {
+     "Fn::GetAtt": [
+      "StateMachineRoleB840431D",
+      "Arn"
+     ]
+    }
+   },
+   "DependsOn": [
+    "StateMachineRoleDefaultPolicyDF1E6607",
+    "StateMachineRoleB840431D"
+   ],
+   "UpdateReplacePolicy": "Delete",
+   "DeletionPolicy": "Delete"
+  }
+ },
+ "Parameters": {
+  "BootstrapVersion": {
+   "Type": "AWS::SSM::Parameter::Value<String>",
+   "Default": "/cdk-bootstrap/hnb659fds/version",
+   "Description": "Version of the CDK Bootstrap resources in this environment, automatically retrieved from SSM Parameter Store. [cdk:skip]"
+  }
+ },
+ "Rules": {
+  "CheckBootstrapVersion": {
+   "Assertions": [
+    {
+     "Assert": {
+      "Fn::Not": [
+       {
+        "Fn::Contains": [
+         [
+          "1",
+          "2",
+          "3",
+          "4",
+          "5"
+         ],
+         {
+          "Ref": "BootstrapVersion"
+         }
+        ]
+       }
+      ]
+     },
+     "AssertDescription": "CDK bootstrap stack version 6 required. Please run 'cdk bootstrap' with a recent version of the CDK CLI."
+    }
+   ]
+  }
+ }
+}