Merge branch 'master' into otaviom/multiple-permissions

.devcontainer.json

@@ -1,8 +1,8 @@
 {
  "name": "Dev Container Definition - AWS CDK",
- "image": "jsii/superchain",
+ "image": "jsii/superchain:1-buster-slim",
  "postCreateCommand": "yarn build --skip-test --no-bail --skip-prereqs --skip-compat",
  "extensions": [
  "[email protected]"
  ]
-}
+}

.github/dependabot.yml

@@ -11,3 +11,10 @@ updates:
  labels:
  - "auto-approve"
  open-pull-requests-limit: 5
+ - package-ecosystem: "pip"
+ directory: "/packages/@aws-cdk/lambda-layer-awscli"
+ schedule:
+ interval: "weekly"
+ labels:
+ - "auto-approve"
+ open-pull-requests-limit: 5

.github/workflows/cr-checklist.yml

@@ -9,7 +9,7 @@ jobs:
  name: Creates a checklist for PRs that contain changes to custom resources
  steps:
  - name: Checkout repo
- uses: actions/checkout@v2
+ uses: actions/checkout@v3
  - name: Dynamic checklist action
  uses: vishalsinha21/dynamic-checklist@v1
  with:

.github/workflows/pr-linter.yml

@@ -21,7 +21,7 @@ jobs:
  steps:
 
  - name: Checkout
- uses: actions/checkout@v2
+ uses: actions/checkout@v3
 
  - name: Install & Build prlint
  run: yarn install --frozen-lockfile && cd tools/@aws-cdk/prlint && yarn build+test

.github/workflows/v2-pull-request.yml

@@ -23,7 +23,7 @@ jobs:
  runs-on: ubuntu-latest
  steps:
  - name: checkout
- uses: actions/checkout@v2
+ uses: actions/checkout@v3
  with:
  branch: ${{ github.event.pull_request.head.ref }}
  token: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/yarn-upgrade.yml

@@ -15,10 +15,10 @@ jobs:
  steps:
 
  - name: Check Out
- uses: actions/checkout@v2
+ uses: actions/checkout@v3
 
  - name: Set up Node
- uses: actions/setup-node@v2.5.1
+ uses: actions/setup-node@v3
  with:
  node-version: 12
 
@@ -49,6 +49,7 @@ jobs:
  # We special-case typescript because it's not semantically versionned
  # We special-case constructs because we want to stay in control of the minimum compatible version
  # We special-case lerna because we have a patch on it that stops applying if Lerna upgrades. Remove this once https:/lerna/lerna/pull/2874 releases.
+ # We special-case aws-sdk-mock because of breaking changes in type exports https:/dwyl/aws-sdk-mock/pull/260. We are not respecting `@ts-ignore`
  run: |-
  # Upgrade dependencies at repository root
  ncu --upgrade --filter=@types/node,@types/fs-extra --target=minor
@@ -57,7 +58,7 @@ jobs:
  # Upgrade all the packages
  lerna exec --parallel ncu -- --upgrade --filter=@types/node,@types/fs-extra --target=minor
  lerna exec --parallel ncu -- --upgrade --filter=typescript --target=patch
- lerna exec --parallel ncu -- --upgrade --reject='@types/node,@types/fs-extra,constructs,typescript,aws-sdk,${{ steps.list-packages.outputs.list }}' --target=minor
+ lerna exec --parallel ncu -- --upgrade --reject='@types/node,@types/fs-extra,constructs,typescript,aws-sdk,aws-sdk-mock,${{ steps.list-packages.outputs.list }}' --target=minor
  # This will ensure the current lockfile is up-to-date with the dependency specifications (necessary for "yarn update" to run)
  - name: Run "yarn install"
  run: yarn install
@@ -86,7 +87,7 @@ jobs:
  runs-on: ubuntu-latest
  steps:
  - name: Check Out
- uses: actions/checkout@v2
+ uses: actions/checkout@v3
 
  - name: Download patch
  uses: actions/download-artifact@v2

.mergify.yml

@@ -10,7 +10,7 @@ pull_request_rules:
  label:
  add: [ contribution/core ]
  conditions:
- - author~=^(eladb|RomainMuller|garnaat|nija-at|skinny85|rix0rrr|NGL321|Jerry-AWS|MrArnoldPalmer|NetaNir|iliapolo|njlynch|ericzbeard|ccfife|fulghum|pkandasamy91|SoManyHs|uttarasridhar|otaviomacedo|BenChaimberg|madeline-k|BryanPan342|kaizen3031593|comcalvi|Chriscbr|corymhall|peterwoodworth|ryparker)$
+ - author~=^(eladb|RomainMuller|garnaat|nija-at|skinny85|rix0rrr|NGL321|Jerry-AWS|MrArnoldPalmer|NetaNir|iliapolo|njlynch|ericzbeard|ccfife|fulghum|pkandasamy91|SoManyHs|uttarasridhar|otaviomacedo|BenChaimberg|madeline-k|BryanPan342|kaizen3031593|comcalvi|Chriscbr|corymhall|peterwoodworth|ryparker|TheRealAmazonKendra)$
  - -label~="contribution/core"
  - name: automatic merge
  actions:

CONTRIBUTING.md

@@ -22,7 +22,7 @@ let us know if it's not up-to-date (even better, submit a PR with your correcti
  - [Step 5: Merge](#step-5-merge)
 - [Breaking Changes](#breaking-changes)
 - [Documentation](#documentation)
- - [rosetta](#rosetta)
+ - [Rosetta](#rosetta)
 - [Tools](#tools)
  - [Linters](#linters)
  - [cfn2ts](#cfn2ts)
@@ -217,6 +217,8 @@ Work your magic. Here are some guidelines:
  Watch out for their error messages and adjust your code accordingly.
 * Every change requires a unit test
 * If you change APIs, make sure to update the module's README file
+ * When you add new examples to the module's README file, you must also ensure they compile - the PR build will fail
+ if they do not. To learn more about how to ensure that they compile, see [Documentation](#documentation).
 * Try to maintain a single feature/bugfix per pull request. It's okay to introduce a little bit of housekeeping
  changes along the way, but try to avoid conflating multiple features. Eventually, all these are going to go into a
  single commit, so you can use that to frame your scope.
@@ -508,7 +510,7 @@ the README for the `aws-ec2` module - https://docs.aws.amazon.com/cdk/api/latest
 
 ### Rosetta
 
-The README file contains code snippets written as typescript code.  Code snippets typed in fenced code blocks
+The README file contains code snippets written as typescript code. Code snippets typed in fenced code blocks
 (such as `` ```ts ``) will be automatically extracted, compiled and translated to other languages when the
 during the [pack](#pack) step. We call this feature 'rosetta'.
 
@@ -541,11 +543,12 @@ When no fixture is specified, the fixture with the name
 `rosetta/default.ts-fixture` will be used if present. `nofixture` can be used to
 opt out of that behavior.
 
-In an `@example` block, which is unfenced, the first line of the example can
-contain three slashes to achieve the same effect:
+In an `@example` block, which is unfenced, additional information pertaining to
+the example can be provided via the `@exampleMetadata` tag:
 
 ```
 /**
+ * @exampleMetadata fixture=with-bucket
  * @example
  * /// fixture=with-bucket
  * bucket.addLifecycleTransition({ ...props });
@@ -582,21 +585,21 @@ cases where some of those do not apply - good judgement is to be applied):
  // ...rest of the example...
  ```
 
-- Within `.ts-fixture` files, make use of `declare` statements instead of
- writing a compatible value (this will make your fixtures more durable):
+- Make use of `declare` statements directly in examples for values that are
+ necessary for compilation but unimportant to the example:
 
  ```ts
- // An hypothetical 'rosetta/default.ts-fixture' file in `@aws-cdk/core`
- import * as kms from '@aws-cdk/aws-kms';
- import * as s3 from '@aws-cdk/aws-s3';
- import { StackProps } from '@aws-cdk/core';
-
- declare const kmsKey: kms.IKey;
- declare const bucket: s3.Bucket;
-
- declare const props: StackProps;
+ // An example about adding a stage to a pipeline in the @aws-cdk/pipelines library
+ declare const pipeline: pipelines.CodePipeline;
+ declare const myStage: Stage;
+ pipeline.addStage(myStage); 
  ```
 
+- Utilize the `default.ts-fixture` that already exists rather than writing new
+ `.ts-fixture` files. This is because values stored in `.ts-fixture` files do
+ not surface to the examples visible in the docs, so while they help successful
+ compilation, they do not help users understand the example.
+
 ## Tools (Advanced)
 
 ### scripts/foreach.sh
@@ -662,7 +665,7 @@ extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-e
 
 #### pkglint
 
-The `pkglint` tool "lints" package.json files across the repo according to [rules.ts](tools/pkglint/lib/rules.ts).
+The `pkglint` tool "lints" package.json files across the repo according to [rules.ts](tools/@aws-cdk/pkglint/lib/rules.ts).
 
 To evaluate (and attempt to fix) all package linting issues in the repo, run the following command from the root of the
 repository (after bootstrapping):

design/aws-ecs/aws-ecs-fargate-capacity-providers.md

@@ -2,7 +2,7 @@
 
 ## Objective
 
-Since Capacity Providers are now supported in CloudFormation, incorporating support for Fargate Spot capacity has been one of the [top asks](https:/aws/aws-cdk/issues?q=is%3Aissue+is%3Aopen+label%3A%40aws-cdk%2Faws-ecs+sort%3Areactions-%2B1-desc) for the ECS CDK module, with over 60 customer reactions. While there are still some outstanding issues regarding capacity provider support in general, specifically regarding cyclic workflows with named clusters (See: [CFN issue](http://%20https/aws/containers-roadmap/issues/631#issuecomment-702580141)), we should be able to move ahead with supporting `FARGATE` and `FARGATE_SPOT` capacity providers with our existing FargateService construct.
+Since Capacity Providers are now supported in CloudFormation, incorporating support for Fargate Spot capacity has been one of the [top asks](https:/aws/aws-cdk/issues?q=is%3Aissue+is%3Aopen+label%3A%40aws-cdk%2Faws-ecs+sort%3Areactions-%2B1-desc) for the ECS CDK module, with over 60 customer reactions. While there are still some outstanding issues regarding capacity provider support in general, specifically regarding cyclic workflows with named clusters (See: [CFN issue](https:/aws/containers-roadmap/issues/631#issuecomment-702580141)), we should be able to move ahead with supporting `FARGATE` and `FARGATE_SPOT` capacity providers with our existing FargateService construct.
 
 See: https:/aws/aws-cdk/issues/5850
 
@@ -118,4 +118,3 @@ One alternative considered was to provide a more magical experience by populatin
 For future extensibility, we can however add an `addCapacityProvider` method on the Cluster resource, to allow modifying the cluster CapacityProviders field post-construction.
 
 Another option would be to create a new FargateCluster resource, that would have the two Fargate capacity providers set by default. The main advantage with this alternative would be that it would be consistent with the current Console experience, which sets the Fargate capacity providers for you if you choose the “Networking Only” cluster template via the cluster wizard. The downside is that it would be a more restrictive resource model that would go back on the decision to have a single generic ECS Cluster resource that could potentially contain both Fargate and EC2 services or tasks. Given that we are moving towards more generic versions of ECS resources, this is not a preferable solution. That being said, in the current iteration we can set the Fargate Capacity Providers on the cluster by default, but put them behind a feature flag, which we would be able to remove in the v2 version of the ECS module. Using the feature flag would ensure that there would not be a diff in the generated CFN template for existing customers defining ECS clusters in their stack who redeploy using an updated version of the CDK.
-

package.json

@@ -16,23 +16,25 @@
  },
  "devDependencies": {
  "@yarnpkg/lockfile": "^1.1.0",
- "cdk-generate-synthetic-examples": "^0.1.3",
+ "cdk-generate-synthetic-examples": "^0.1.6",
  "conventional-changelog-cli": "^2.2.2",
  "fs-extra": "^9.1.0",
  "graceful-fs": "^4.2.9",
  "jest-junit": "^13.0.0",
- "jsii-diff": "^1.52.1",
- "jsii-pacmak": "^1.52.1",
- "jsii-reflect": "^1.52.1",
- "jsii-rosetta": "^1.52.1",
+ "jsii-diff": "^1.54.0",
+ "jsii-pacmak": "^1.54.0",
+ "jsii-reflect": "^1.54.0",
+ "jsii-rosetta": "^1.54.0",
  "lerna": "^4.0.0",
  "patch-package": "^6.4.7",
+ "semver": "^6.3.0",
  "standard-version": "^9.3.2",
  "typescript": "~3.9.10"
  },
  "resolutions": {
  "colors": "1.4.0",
- "string-width": "^4.2.3"
+ "string-width": "^4.2.3",
+ "markdown-it": "^12.3.2"
  },
  "repository": {
  "type": "git",

packages/@aws-cdk-containers/ecs-service-extensions/package.json

@@ -37,14 +37,14 @@
  },
  "license": "Apache-2.0",
  "devDependencies": {
- "@types/jest": "^27.4.0",
+ "@types/jest": "^27.4.1",
  "@aws-cdk/cdk-build-tools": "0.0.0",
  "@aws-cdk/cdk-integ-tools": "0.0.0",
  "@aws-cdk/aws-autoscaling": "0.0.0",
  "@aws-cdk/cfn2ts": "0.0.0",
- "jest": "^27.4.7",
+ "jest": "^27.5.1",
  "@aws-cdk/pkglint": "0.0.0",
- "@aws-cdk/assert-internal": "0.0.0"
+ "@aws-cdk/assertions": "0.0.0"
  },
  "dependencies": {
  "@aws-cdk/aws-applicationautoscaling": "0.0.0",

packages/@aws-cdk-containers/ecs-service-extensions/test/appmesh.test.ts

@@ -1,4 +1,4 @@
-import '@aws-cdk/assert-internal/jest';
+import { Match, Template } from '@aws-cdk/assertions';
 import * as appmesh from '@aws-cdk/aws-appmesh';
 import * as ecs from '@aws-cdk/aws-ecs';
 import * as cdk from '@aws-cdk/core';
@@ -34,7 +34,7 @@ describe('appmesh', () => {
 
  // THEN
  // Ensure that task has an App Mesh sidecar
- expect(stack).toHaveResource('AWS::ECS::TaskDefinition', {
+ Template.fromStack(stack).hasResourceProperties('AWS::ECS::TaskDefinition', {
  ContainerDefinitions: [
  {
  Cpu: 256,
@@ -210,7 +210,7 @@ describe('appmesh', () => {
  });
 
  // Ensure that the service has the right settings
- expect(stack).toHaveResource('AWS::ECS::Service', {
+ Template.fromStack(stack).hasResourceProperties('AWS::ECS::Service', {
  Cluster: {
  Ref: 'productionenvironmentclusterC6599D2D',
  },
@@ -256,8 +256,6 @@ describe('appmesh', () => {
  Ref: 'myservicetaskdefinitionF3E2D86F',
  },
  });
-
-
  });
 
  test('should have the right maximumPercentage at desired count == 1', () => {
@@ -288,15 +286,13 @@ describe('appmesh', () => {
  desiredCount: 1,
  });
 
- expect(stack).toHaveResourceLike('AWS::ECS::Service', {
+ Template.fromStack(stack).hasResourceProperties('AWS::ECS::Service', {
  DeploymentConfiguration: {
  MaximumPercent: 200,
  MinimumHealthyPercent: 100,
  },
  DesiredCount: 1,
  });
-
-
  });
 
  test('should have the right maximumPercentage at desired count == 2', () => {
@@ -327,15 +323,13 @@ describe('appmesh', () => {
  desiredCount: 2,
  });
 
- expect(stack).toHaveResourceLike('AWS::ECS::Service', {
+ Template.fromStack(stack).hasResourceProperties('AWS::ECS::Service', {
  DeploymentConfiguration: {
  MaximumPercent: 150,
  MinimumHealthyPercent: 100,
  },
  DesiredCount: 2,
  });
-
-
  });
 
  test('should have the right maximumPercentage at desired count == 3', () => {
@@ -366,15 +360,13 @@ describe('appmesh', () => {
  desiredCount: 3,
  });
 
- expect(stack).toHaveResourceLike('AWS::ECS::Service', {
+ Template.fromStack(stack).hasResourceProperties('AWS::ECS::Service', {
  DeploymentConfiguration: {
  MaximumPercent: 150,
  MinimumHealthyPercent: 100,
  },
  DesiredCount: 3,
  });
-
-
  });
 
  test('should have the right maximumPercentage at desired count == 4', () => {
@@ -405,15 +397,13 @@ describe('appmesh', () => {
  desiredCount: 4,
  });
 
- expect(stack).toHaveResourceLike('AWS::ECS::Service', {
+ Template.fromStack(stack).hasResourceProperties('AWS::ECS::Service', {
  DeploymentConfiguration: {
  MaximumPercent: 125,
  MinimumHealthyPercent: 100,
  },
  DesiredCount: 4,
  });
-
-
  });
 
  test('should have the right maximumPercentage at desired count > 4', () => {
@@ -444,15 +434,13 @@ describe('appmesh', () => {
  desiredCount: 8,
  });
 
- expect(stack).toHaveResourceLike('AWS::ECS::Service', {
+ Template.fromStack(stack).hasResourceProperties('AWS::ECS::Service', {
  DeploymentConfiguration: {
  MaximumPercent: 125,
  MinimumHealthyPercent: 100,
  },
  DesiredCount: 8,
  });
-
-
  });
 
  test('should be able to create multiple App Mesh enabled services and connect', () => {
@@ -516,9 +504,7 @@ describe('appmesh', () => {
  greeterService.connectTo(greetingService);
 
  // THEN
- expect(stack).toHaveResource('AWS::ECS::TaskDefinition');
-
-
+ Template.fromStack(stack).hasResource('AWS::ECS::TaskDefinition', Match.anyValue());
  });
 
  test('should detect when attempting to connect services from two different envs', () => {
@@ -572,7 +558,5 @@ describe('appmesh', () => {
  expect(() => {
  developmentNameService.connectTo(productionNameService);
  }).toThrow(/Unable to connect service 'name-development' in environment 'development' to service 'name-production' in environment 'production' because services can not be connected across environment boundaries/);
-
-
  });
 });