chore(release): 2.90.0 (#26642)

See [CHANGELOG](https://github.com/aws/aws-cdk/blob/bump/2.90.0/CHANGELOG.md)

Author: mergify[bot]

.github/workflows/close-stale-issues.yml

@@ -8,6 +8,8 @@ on:
 
 jobs:
   cleanup:
+    # this workflow will always fail in forks; bail if this isn't running in the upstream
+    if: github.repository == 'aws/aws-cdk'
     permissions:
       issues: write
       contents: read

.github/workflows/close-stale-prs.yml

@@ -5,6 +5,8 @@ on:
   workflow_dispatch:
 jobs:
   close-stale-prs:
+    # this workflow will always fail in forks; bail if this isn't running in the upstream
+    if: github.repository == 'aws/aws-cdk'
     permissions:
       pull-requests: write
     runs-on: ubuntu-latest

.github/workflows/handle-stale-discussions.yml

@@ -7,6 +7,8 @@ on:
 
 jobs:
   handle-stale-discussions:
+    # this workflow will always fail in forks; bail if this isn't running in the upstream
+    if: github.repository == 'aws/aws-cdk'
     name: Handle stale discussions
     runs-on: ubuntu-latest
     permissions:
@@ -15,4 +17,4 @@ jobs:
       - name: Stale discussions action
         uses: aws-github-ops/handle-stale-discussions@v1
         env:
-          GITHUB_TOKEN:  ${{secrets.GITHUB_TOKEN}}
+          GITHUB_TOKEN:  ${{secrets.GITHUB_TOKEN}}

.github/workflows/repo-metrics.yml

@@ -10,6 +10,8 @@ permissions:
 
 jobs:
   build:
+    # this workflow will always fail in forks; bail if this isn't running in the upstream
+    if: github.repository == 'aws/aws-cdk'
     name: metrics
     runs-on: ubuntu-latest
 

.github/workflows/spec-update.yml

@@ -8,6 +8,8 @@ on:
 
 jobs:
   update-spec:
+    # this workflow will always fail in forks; bail if this isn't running in the upstream
+    if: github.repository == 'aws/aws-cdk'
     name: Update AWS Service Spec packages
     permissions:
       contents: read

CHANGELOG.v2.alpha.md

@@ -2,6 +2,19 @@
 
 All notable changes to this project will be documented in this file. See [standard-version](https://github.com/conventional-changelog/standard-version) for commit guidelines.
 
+## [2.90.0-alpha.0](https://github.com/aws/aws-cdk/compare/v2.89.0-alpha.0...v2.90.0-alpha.0) (2023-08-04)
+
+
+### Features
+
+* **glue:** glue tables can include storage parameters ([#24498](https://github.com/aws/aws-cdk/issues/24498)) ([f1df9ab](https://github.com/aws/aws-cdk/commit/f1df9ab2ba29051016f052ffe9a629ca698289b8)), closes [#23132](https://github.com/aws/aws-cdk/issues/23132)
+
+
+### Bug Fixes
+
+* **app-staging-synthesizer:** misleading error message about environment-agnostic/aware stacks ([#26607](https://github.com/aws/aws-cdk/issues/26607)) ([7e2f335](https://github.com/aws/aws-cdk/commit/7e2f335b60bda549c6abd628863b3535f9e9f153))
+* **synthetics:** updated handler validation ([#26569](https://github.com/aws/aws-cdk/issues/26569)) ([1eaec92](https://github.com/aws/aws-cdk/commit/1eaec92cd7cc201c92990ab1f57a8299107327db)), closes [#26540](https://github.com/aws/aws-cdk/issues/26540)
+
 ## [2.89.0-alpha.0](https://github.com/aws/aws-cdk/compare/v2.88.0-alpha.0...v2.89.0-alpha.0) (2023-07-28)
 
 

CHANGELOG.v2.md

@@ -2,6 +2,26 @@
 
 All notable changes to this project will be documented in this file. See [standard-version](https://github.com/conventional-changelog/standard-version) for commit guidelines.
 
+## [2.90.0](https://github.com/aws/aws-cdk/compare/v2.89.0...v2.90.0) (2023-08-04)
+
+
+### Features
+
+* **aws-cdk-lib:** ADOT Lambda Layer v0.31.0 ([#26505](https://github.com/aws/aws-cdk/issues/26505)) ([03c6f6f](https://github.com/aws/aws-cdk/commit/03c6f6fb667a1d7034537b514103215bb949a8da))
+* **core:** new RemovalPolicy.RETAIN_EXCEPT_ON_CREATE to only retain resources that have been successfully created ([#26602](https://github.com/aws/aws-cdk/issues/26602)) ([c84666c](https://github.com/aws/aws-cdk/commit/c84666c22658e22956d79b83d0d226278d829f9d)), closes [#26595](https://github.com/aws/aws-cdk/issues/26595)
+* **core:** support ssh build arg in DockerImageAsset ([#26356](https://github.com/aws/aws-cdk/issues/26356)) ([7b3d381](https://github.com/aws/aws-cdk/commit/7b3d3813124c6c1dfa912c4fbe20772c84a0ffc6))
+* **stepfunctions:** allow setting comment on state machine ([#25858](https://github.com/aws/aws-cdk/issues/25858)) ([6a70b4f](https://github.com/aws/aws-cdk/commit/6a70b4fe83f6ab2571086454909aae13ec9959fb))
+* update AWS Service Spec ([#26579](https://github.com/aws/aws-cdk/issues/26579)) ([6c588da](https://github.com/aws/aws-cdk/commit/6c588da2c6b1c2f5a53fb9151c84c7298ce2427e))
+
+
+### Bug Fixes
+
+* **cli:** specifying --quiet does not suppress asset building and publishing logs ([#26493](https://github.com/aws/aws-cdk/issues/26493)) ([b12bc67](https://github.com/aws/aws-cdk/commit/b12bc676bd5f99843b224839bc32504b47f0599e)), closes [#26265](https://github.com/aws/aws-cdk/issues/26265)
+* **ec2:** flowLogName property for FlowLog construct does not work ([#26371](https://github.com/aws/aws-cdk/issues/26371)) ([f910f78](https://github.com/aws/aws-cdk/commit/f910f7840f9ceb02780dc3b08d548fb7a2072e58)), closes [#26370](https://github.com/aws/aws-cdk/issues/26370)
+* **ecr:** error handling compatible with aws sdk v3 ([#26608](https://github.com/aws/aws-cdk/issues/26608)) ([300989a](https://github.com/aws/aws-cdk/commit/300989a675bd9fc9c2829c5115efe34e753e0976)), closes [#26433](https://github.com/aws/aws-cdk/issues/26433)
+* **ecs:** unclear docs on valid ec2 task definition placement constraints and no validation of input [#25933](https://github.com/aws/aws-cdk/issues/25933) ([#26384](https://github.com/aws/aws-cdk/issues/26384)) ([4c57f45](https://github.com/aws/aws-cdk/commit/4c57f4550917f5a280a5c0a79f2ae03325ef3a66))
+* **logs:** LogRetention Custom Resource does not use Node18 ([#26609](https://github.com/aws/aws-cdk/issues/26609)) ([54e64c7](https://github.com/aws/aws-cdk/commit/54e64c7eb0435bd043affe4bbd8dc2fdbddbcffd)), closes [#26461](https://github.com/aws/aws-cdk/issues/26461)
+
 ## [2.89.0](https://github.com/aws/aws-cdk/compare/v2.88.0...v2.89.0) (2023-07-28)
 
 

CONTRIBUTING.md

@@ -352,8 +352,8 @@ assertions against the deployed infrastructure.
 ```
 
 Examples:
-* [integ.destinations.ts](https://github.com/aws/aws-cdk/blob/master/packages/%40aws-cdk/aws-lambda-destinations/test/integ.destinations.ts#L7)
-* [integ.put-events.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-stepfunctions-tasks/test/eventbridge/integ.put-events.ts)
+* [integ.destinations.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk-testing/framework-integ/test/aws-lambda-destinations/test/integ.destinations.ts#L7)
+* [integ.put-events.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk-testing/framework-integ/test/aws-stepfunctions-tasks/test/eventbridge/integ.put-events.ts)
 
 **What if you cannot run integration tests**
 

INTEGRATION_TESTS.md

@@ -49,8 +49,8 @@ an integration test for the new feature can ensure that it works and avoid unnec
 
 **3. Involves configuring resource types across services (i.e. integrations)**
 For example, you are adding functionality that allows for service x to integrate with service y.
-A good example of this is the [aws-stepfunctions-tasks](./packages/@aws-cdk/aws-stepfunctions-tasks) or
-[aws-apigatewayv2-integrations](./packages/@aws-cdk/aws-apigatewayv2-integrations) modules. Both of these
+A good example of this is the [aws-stepfunctions-tasks](./packages/aws-cdk-lib/aws-stepfunctions-tasks) or
+[aws-apigatewayv2-integrations-alpha](./packages/@aws-cdk/aws-apigatewayv2-integrations-alpha) modules. Both of these
 have L2 constructs that provide functionality to integrate services.
 
 Sometimes these integrations involve configuring/formatting json/vtl or some other type of data.
@@ -82,8 +82,8 @@ Lambda Function would look like this:
 
 _integ.lambda.ts_
 ```ts
-import * as iam from '@aws-cdk/aws-iam';
-import * as cdk from '@aws-cdk/core';
+import * as iam from 'aws-cdk-lib/aws-iam';
+import * as cdk from 'aws-cdk-lib/core';
 import * as lambda from '../lib';
 import * as integ from '@aws-cdk/integ-tests-alpha';
 
@@ -230,11 +230,11 @@ to deploy the Lambda Function _and_ then rerun the assertions to ensure that the
 ### Assertions
 
 Sometimes it is necessary to perform some form of _assertion_ against the deployed infrastructure to validate that the
-test succeeds. A good example of this is the `@aws-cdk/aws-stepfunctions-tasks` module which creates integrations between
+test succeeds. A good example of this is the `aws-cdk-lib/aws-stepfunctions-tasks` module which creates integrations between
 AWS StepFunctions and other AWS services. 
 
-If we look at the [integ.put-events.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-stepfunctions-tasks/test/eventbridge/integ.put-events.ts)
-integration test we can see that we are creating an `@aws-cdk/aws-events.EventBus` along with a `@aws-cdk/aws-stepfunctions.StateMachine`
+If we look at the [integ.put-events.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk-testing/framework-integ/test/aws-stepfunctions-tasks/test/eventbridge/integ.put-events.ts)
+integration test we can see that we are creating an `aws-cdk-lib/aws-events.EventBus` along with a `aws-cdk-lib/aws-stepfunctions.StateMachine`
 which will send an event to the `EventBus`. In a typical integration test we would just deploy the test and the fact that the
 infrastructure deployed successfully would be enough of a validation that the test succeeded. In this case though, we ideally
 want to validate that the _integration_ connecting `StepFunctions` to the `EventBus` has been setup correctly, and the only
@@ -269,8 +269,8 @@ Not every test requires an assertion. We typically do not need to assert CloudFo
 with Encryption, we do not need to assert that Encryption is set on the bucket. We can trust that the CloudFormation behavior works.
 Some things you should look for in deciding if the test needs an assertion:
 
-- Integrations between services (i.e. integration libraries like `@aws-cdk/aws-lambda-destinations`, `@aws-cdk/aws-stepfunctions-tasks`, etc)
-- Anything that bundles or deploys custom code (i.e. does a Lambda function bundled with `@aws-cdk/aws-lambda-nodejs` still invoke or did we break bundling behavior)
+- Integrations between services (i.e. integration libraries like `aws-cdk-lib/aws-lambda-destinations`, `aws-cdk-lib/aws-stepfunctions-tasks`, etc)
+- Anything that bundles or deploys custom code (i.e. does a Lambda function bundled with `aws-cdk-lib/aws-lambda-nodejs` still invoke or did we break bundling behavior)
 - IAM/Networking connections.
   - This one is a bit of a judgement call. Most things do not need assertions, but sometimes we handle complicated configurations involving IAM permissions or
     Networking access.

ROADMAP.md

@@ -1,48 +1,64 @@
 # AWS CDK Roadmap
 
-The [AWS CDK Roadmap] lets developers know about our upcoming features and priorities to help them plan how to best leverage the CDK and identify opportunities to contribute to the project. The roadmap provides a high-level view of our work in progress across the [aws-cdk], [aws-cdk-rfcs], and [jsii] repositories, and creates an opportunity for customers to engage in a conversation with AWS CDK engineers to give us direct feedback.
+The [AWS CDK Roadmap] lets developers know about our upcoming features and priorities to help them 
+plan how to best leverage the CDK and identify opportunities to contribute to the project. The roadmap 
+provides a high-level view of our work in progress across the [aws-cdk], [aws-cdk-rfcs], and [jsii] 
+repositories, and creates an opportunity for customers to engage in a conversation with AWS CDK engineers to 
+give us direct feedback.
 
-[AWS CDK Roadmap]: https://github.com/orgs/aws/projects/7
+[AWS CDK Roadmap]: https://github.com/orgs/aws/projects/88
 [aws-cdk]: https://github.com/aws/aws-cdk
 [aws-cdk-rfcs]: https://github.com/aws/aws-cdk-rfcs
 [jsii]: https://github.com/aws/jsii
 
-## Roadmap FAQs
+## Tenets
+The core values for CDK on how to prioritize work, keep engaged with the community and deliver what matters.
+1. **Be transparent**
 
-**Q: How do you manage the roadmap?**
+The AWS CDK team’s current work should be easily visible.
+
+2. **Listen to customers**
+
+Allow them to participate in design decisions and to vote on and propose new AWS CDK features. We will periodically re-prioritize the roadmap based on customer feedback.
 
-A: We know that our customers are making decisions and plans based on what we
-are developing, and we want to provide the information they need to be successful. Our roadmap management tenets are:
+3. **Stay up-to-date**
 
-* **Be transparent** with customers about the AWS CDK team’s work in progress
-* **Listen to customers,** allowing them to participate in design decisions and to vote on and propose new AWS CDK
-  features. We will periodically re-prioritize the roadmap based on customer feedback
-* **Stay up-to-date,** or we will lose customer trust
-* **Provide the right level of detail** so customers can easily see what we’re working on at a glance, without being
-  overwhelmed by minutiae
-* **Guide the community** on what AWS CDK constructs or features to contribute without the risk of conflicting with work
-  already in progress
+Be informed and incorporate best practices.
 
-**Q: What do the roadmap project board columns mean?**
+4. **Provide the right level of detail**
 
-A: There are four columns on the roadmap project board:
+The overview should indicate all work in progress at a glance, while allowing a deep dive into the details via provided references.
 
-* **Researching** - We’re thinking about it, but cannot commit if, or when, we will work on items in this list.
+5. **Guide the community**
+
+Align on what can be worked on that is not currently handled by the team.
+Offer help and unblock contributors in their efforts.
+
+## Roadmap FAQs
+**Q: How do you manage the roadmap?**
+
+A: CDK customers are making decisions and plans based on what we are developing. We strive to provide the 
+required information, when that is not sufficient, we take note of the feedback we receive and iterate on how 
+to bring improvements to our current processes and available information.
+
+**Q: How do you mark work in progress?**
+
+A: For the [aws-cdk] repository, any issue that is currently worked on will have the `CDK Construct Squad` project 
+listed, with the current status.
+
+* **Needs Review** - We’re thinking about it, but cannot commit if, or when, we will work on items in this list.
   This means we are still designing the feature and evaluating how it might work. This is the phase when we collect
   customer use cases and feedback on how they want to see something implemented. There is no firm commitment to deliver
-  functionality listed in the Researching column, and there might be situations that require us to move items from the
-  roadmap back to the backlog.
-* **We’re working on it** - In progress, but further out. We have made an implied commitment to work on items in this
-  bucket, they have some level of design spec’ed out, and a developer assigned to them. Items might linger in this
-  bucket as we work through the implementation details, or scope stuff out. Think several months out until a developer
-  preview release, give or take.
-* **Developer preview** - It’s available now as a release candidate. Items will spend extended periods of time in
-  developer preview as we conduct user acceptance testing and accumulate sufficient usage to declare the API stable and
-  ready for general availability. We will only make breaking changes to developer preview modules when we need to address unforeseen use cases or issues. Not all
-  features, such as enhancements to the CDK CLI, will have a developer preview phase. In these cases the tracking issue
-  is moved directly to the Shipped bucket when released.
-* **Shipped** - It’s available now, fully supported by AWS, and we guarantee the API is stable and safe to use in
-  production.
+  functionality listed in the Needs Review column, and there might be situations where we remove items from the Needs
+  Review column.
+* **Backlog** - We want to do this, but no one has picked it up yet. We have made an implied commitment to work on items
+  in this bucket, they have some level of design spec’ed out. Items might linger in this bucket as we work through the implementation details, or scope stuff out. Think several months out until a developer preview release, give or take.
+* **In Progress** - Someone on the CDK team is actively working on this. If all goes well, issues in this bucket should
+  be released in the coming weeks.
+* **In review** - It’s implementation is done and we are reviewing the code.
+* **Done** - It’s available now, fully supported by AWS.
+
+For the [aws-cdk-rfcs], the README file contains the overview and statuses. They can also be checked per RFC by selecting any of the relevant [issues](https://github.com/aws/aws-cdk-rfcs/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc) and seeing how far along is its `Workflow`.
 
 **Q: How do items on the roadmap move across the project board?**
 
@@ -71,15 +87,15 @@ A: We create a tracking issue for each CDK feature, AWS Construct Library module
 
 **Q: How can I provide feedback on the roadmap or ask for more information about a feature?**
 
-A: Please open an issue!
+A: Please open an issue! Or engage by 👍 existing ones.
 
 **Q: How can I request a feature be added to the roadmap?**
 
 A: Please open an issue! Community submitted issues will be tagged “feature-request” and will be reviewed by the team.
 
 **Q: Can I “+1” tracking issues and feature requests?**
 
-A: We strongly encourage you to do so, as it helps us understand which issues will have the broadest impact. You can navigate to the issue details page and add a reaction. There are six types of reactions (thumbs up “+1”, thumbs down “-1”, confused, heart, watching, laugh, and hooray) you can use to help us decide which items will benefit you most.
+A: We strongly encourage you to do so, as it helps us understand which issues will have the broadest impact. You can navigate to the issue details page and add a reaction. There are six types of reactions (👍 +1, 👎 -1, 😕 confused, ❤️ heart, 👀 watching, 😄 smile, and 🎉 celebration) you can use to help us decide which items will benefit you most.
 
 **Q: Will you accept a pull request to the aws-cdk repo?**