Merge branch 'master' into huijbers/fix-autoscaling-agg

.gitallowed

@@ -22,3 +22,4 @@ account: '772975370895'
 account: '856666278305'
 account: '840364872350'
 account: '422531588944'
+account: '924023996002'

.github/workflows/auto-approve.yml

@@ -1,7 +1,9 @@
 # Approve PRs with "pr/auto-approve". mergify takes care of the actual merge.
 
 name: auto-approve
-on: pull_request
+on:
+  pull_request:
+    types: [ labeled, unlabeled, opened, synchronize, reopened, ready_for_review, review_requested ]
 
 jobs:
   auto-approve:

.github/workflows/pr-linter.yml

@@ -2,7 +2,15 @@
 # https://github.com/actions/toolkit/blob/master/packages/github/src/context.ts
 
 name: PR Linter
-on: pull_request
+on:
+  pull_request:
+    types:
+      - labeled
+      - unlabeled
+      - edited
+      - opened
+      - synchronize
+      - reopened
 
 jobs:
   validate-pr:

.github/workflows/yarn-upgrade.yml

@@ -16,7 +16,7 @@ jobs:
         uses: actions/checkout@v2
 
       - name: Set up Node
-        uses: actions/setup-node@v2.1.4
+        uses: actions/setup-node@v2.1.5
         with:
           node-version: 10
 

CONTRIBUTING.md

@@ -14,6 +14,7 @@ and let us know if it's not up-to-date (even better, submit a PR with your  corr
   - [Step 4: Commit](#step-4-commit)
   - [Step 5: Pull Request](#step-5-pull-request)
   - [Step 6: Merge](#step-6-merge)
+- [Breaking Changes](#breaking-changes)
 - [Tools](#tools)
   - [Main build scripts](#main-build-scripts)
   - [Partial build tools](#partial-build-tools)
@@ -266,6 +267,143 @@ BREAKING CHANGE: Description of what broke and how to achieve this behavior now
 * Once approved and tested, a maintainer will squash-merge to master and will use your PR title/description as the
   commit message.
 
+## Breaking Changes
+
+Whenever you are making changes, there is a chance for those changes to be
+*breaking* existing users of the library. A change is breaking if there are
+programs that customers could have been writing against the current version
+of the CDK, that will no longer "work correctly" with the proposed new
+version of the CDK.
+
+Breaking changes are not allowed in *stable* libraries¹. They are permissible
+but still *highly discouraged* in experimental libraries, and require explicit
+callouts in the bodies of Pull Requests that introduce them.
+
+> ¹) Note that starting in version 2 of the CDK, the majority of library code will be
+> bundled into a single main CDK library which will be considered stable, and so
+> no code in there can undergo breaking changes.
+
+Breaking changes come in two flavors:
+
+* API surface changes
+* Behavior changes
+
+### API surface changes
+
+This encompasses any changes that affect the shape of the API. Changes that
+will make existing programs fail to compile are not allowed. Typical examples
+of that are:
+
+* Renaming classes or methods
+* Adding required properties to a struct that is used as an input to a constructor
+  or method. This also includes changing a type from nullable to non-nullable.
+* Removing properties from a struct that is returned from a method, or removing
+  properties from a class. This also includes changing a type from non-nullable
+  to nullable.
+
+To see why the latter is a problem, consider the following class:
+
+```ts
+class SomeClass {
+  public readonly count: number;
+  //               ❓ let's say I want to change this to 'count?: number',
+  //                  i.e. make it optional.
+}
+
+// Someone could have written the following code:
+const obj = new SomeClass();
+console.log(obj.count + 1);
+
+// After the proposed change, this code that used to compile fine will now throw:
+console.log(obj.count + 1);
+//          ~~~~~~~~~ Error: Object is possibly 'undefined'.
+```
+
+CDK comes with build tooling to check whether changes you made introduce breaking
+changes to the API surface. In a package directory, run:
+
+```shell
+$ yarn build
+$ yarn compat
+```
+
+To figure out if the changes you made were breaking. See the section [API Compatibility
+Checks](#api-compatibility-checks) for more information.
+
+#### Dealing with breaking API surface changes
+
+If you need to change the type of some API element, introduce a new API
+element and mark the old API element as `@deprecated`.
+
+If you need to pretend to have a value for the purposes of implementing an API
+and you don't actually have a useful value to return, it is acceptable to make
+the property a `getter` and throw an exception (keeping in mind to write error
+messages that will be useful to a user of your construct):
+
+```ts
+class SomeClass implements ICountable {
+  constructor(private readonly _count?: number) {
+  }
+
+  public get count(): number {
+    if (this._count === undefined) {
+      // ✅ DO: throw a descriptive error that tells the user what to do
+      throw new Error('This operation requires that a \'count\' is specified when SomeClass is created.');
+      // ❌ DO NOT: just throw an error like 'count is missing'
+    }
+    return this._count;
+  }
+}
+```
+
+### Behavior changes
+
+These are changes that do not directly affect the compilation of programs
+written against the previous API, but may change their meaning. In practice,
+even though the user didn't change their code, the CloudFormation template
+that gets synthesized is now different.
+
+**Not all template changes are breaking changes!** Consider a user that has
+created a Stack using the previous version of the library, has updated their
+version of the CDK library and is now deploying an update. A behavior change
+is breaking if:
+
+* The update cannot be applied at all
+* The update can be applied but causes service interruption or data loss.
+
+Data loss happens when the [Logical
+ID](https://docs.aws.amazon.com/cdk/latest/guide/identifiers.html#identifiers_logical_ids)
+of a stateful resource changes, or one of the [resource properties that requires
+replacement](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-update-behaviors.html)
+is modified. In both of these cases, CloudFormation will delete the
+resource, and if it was a stateful resource like a database the data in it is now gone.
+
+If a change applies cleanly and does not cause any service interruption, it
+is not breaking. Nevertheless, it might still be wise to avoid those kinds of
+changes as users are understandably wary of unexpected template changes, will
+scrutinize them heavily, and we don't want to cause unnecessary panic and churn
+in our use base.
+
+Determining whether or not behavioral changes are breaking requires expertise
+and judgement on the part of the library owner, and testing.
+
+#### Dealing with breaking behavior changes
+
+Most of the time, behavioral changes will arise because we want to change the
+default value or default behavior of some property (i.e., we want to change the
+interpretation of what it means if the value is missing).
+
+If the new behavior is going to be breaking, the user must opt in to it, either by:
+
+* Adding a new API element (class, property, method, ...) to have users
+  explicitly opt in to the new behavior at the source code level (potentially
+  `@deprecate`ing the old API element); or
+* Use the [feature flag](#feature-flags) mechanism to have the user opt in to the new
+  behavior without changing the source code.
+
+Of these two, the first one is preferred if possible (as feature flags have
+non-local effects which can cause unintended effects).
+
 ## Tools
 
 The CDK is a big project, and at the moment, all of the CDK modules are mastered in a single monolithic repository

DESIGN_GUIDELINES.md

@@ -1,65 +1,5 @@
 # AWS Construct Library Design Guidelines
 
-- [AWS Construct Library Design Guidelines](#aws-construct-library-design-guidelines)
-  - [What's Included](#what-s-included)
-  - [API Design](#api-design)
-    - [Modules](#modules)
-    - [Construct Class](#construct-class)
-    - [Construct Interface](#construct-interface)
-      - [Owned vs. Unowned Constructs](#owned-vs-unowned-constructs)
-      - [Abstract Base](#abstract-base)
-    - [Props](#props)
-      - [Types](#types)
-      - [Defaults](#defaults)
-      - [Flat](#flat)
-      - [Concise](#concise)
-      - [Naming](#naming)
-      - [Property Documentation](#property-documentation)
-      - [Enums](#enums)
-      - [Unions](#unions)
-    - [Attributes](#attributes)
-    - [Configuration](#configuration)
-      - [Prefer Additions](#prefer-additions)
-      - [Dropped Mutations](#dropped-mutations)
-    - [Factories](#factories)
-    - [Imports](#imports)
-      - [“from” Methods](#-from--methods)
-      - [From-attributes](#from-attributes)
-    - [Roles](#roles)
-    - [Resource Policies](#resource-policies)
-    - [VPC](#vpc)
-    - [Grants](#grants)
-    - [Metrics](#metrics)
-    - [Events](#events)
-    - [Connections](#connections)
-    - [Integrations](#integrations)
-    - [State](#state)
-    - [Physical Names - TODO](#physical-names---todo)
-    - [Tags](#tags)
-    - [Secrets](#secrets)
-  - [Project Structure](#project-structure)
-    - [Code Organization](#code-organization)
-  - [Implementation](#implementation)
-    - [General Principles](#general-principles)
-    - [Construct IDs](#construct-ids)
-    - [Errors](#errors)
-      - [Input Validation](#input-validation)
-      - [Avoid Errors If Possible](#avoid-errors-if-possible)
-      - [Never Catch Exceptions](#never-catch-exceptions)
-      - [Post Validation](#post-validation)
-      - [Attached Errors/Warnings](#attached-errors-warnings)
-    - [Tokens](#tokens)
-  - [Documentation](#documentation)
-    - [Inline Documentation](#inline-documentation)
-    - [Readme](#readme)
-  - [Testing](#testing)
-    - [Unit tests](#unit-tests)
-    - [Integration tests](#integration-tests)
-    - [Versioning](#versioning)
-  - [Naming & Style](#naming---style)
-    - [Naming Conventions](#naming-conventions)
-    - [Coding Style](#coding-style)
-
 The AWS Construct Library is a rich class library of CDK constructs which
 represent all resources offered by the AWS Cloud and higher-level constructs for
 achieving common tasks.
@@ -68,6 +8,68 @@ The purpose of this document is to provide guidelines for designing the APIs in
 the AWS Construct Library in order to ensure a consistent and integrated
 experience across the entire AWS surface area.
 
+* [Preface](#preface)
+* [What's Included](#what-s-included)
+* [API Design](#api-design)
+  * [Modules](#modules)
+  * [Construct Class](#construct-class)
+  * [Construct Interface](#construct-interface)
+    * [Owned vs. Unowned Constructs](#owned-vs-unowned-constructs)
+    * [Abstract Base](#abstract-base)
+  * [Props](#props)
+    * [Types](#types)
+    * [Defaults](#defaults)
+    * [Flat](#flat)
+    * [Concise](#concise)
+    * [Naming](#naming)
+    * [Property Documentation](#property-documentation)
+    * [Enums](#enums)
+    * [Unions](#unions)
+  * [Attributes](#attributes)
+  * [Configuration](#configuration)
+    * [Prefer Additions](#prefer-additions)
+    * [Dropped Mutations](#dropped-mutations)
+  * [Factories](#factories)
+  * [Imports](#imports)
+    * [“from” Methods](#-from--methods)
+    * [From-attributes](#from-attributes)
+  * [Roles](#roles)
+  * [Resource Policies](#resource-policies)
+  * [VPC](#vpc)
+  * [Grants](#grants)
+  * [Metrics](#metrics)
+  * [Events](#events)
+  * [Connections](#connections)
+  * [Integrations](#integrations)
+  * [State](#state)
+  * [Physical Names - TODO](#physical-names---todo)
+  * [Tags](#tags)
+  * [Secrets](#secrets)
+* [Project Structure](#project-structure)
+  * [Code Organization](#code-organization)
+* [Implementation](#implementation)
+  * [General Principles](#general-principles)
+  * [Construct IDs](#construct-ids)
+  * [Errors](#errors)
+    * [Avoid Errors If Possible](#avoid-errors-if-possible)
+    * [Error reporting mechanism](#error-reporting-mechanism)
+    * [Throwing exceptions](#throwing-exceptions)
+    * [Never Catch Exceptions](#never-catch-exceptions)
+    * [Attaching (lazy) Validators](#attaching--lazy--validators)
+    * [Attaching Errors/Warnings](#attaching-errors-warnings)
+    * [Error messages](#error-messages)
+  * [Tokens](#tokens)
+* [Documentation](#documentation)
+  * [Inline Documentation](#inline-documentation)
+  * [Readme](#readme)
+* [Testing](#testing)
+  * [Unit tests](#unit-tests)
+  * [Integration tests](#integration-tests)
+  * [Versioning](#versioning)
+* [Naming & Style](#naming---style)
+  * [Naming Conventions](#naming-conventions)
+  * [Coding Style](#coding-style)
+
 ## Preface
 
 As much as possible, the guidelines in this document are enforced using the

link-all.sh

@@ -26,7 +26,7 @@ for module in ${modules}; do
   # according to spec (we look in the bin/ directory instead of the { "scripts"
   # } entry in package.json but it's quite a bit easier.
   if [[ -d $module/bin ]]; then
-    for script in $(find $module/bin -perm /111); do
+    for script in $(find $module/bin -perm +111); do
       echo "${script} => node_modules/.bin/$(basename $script)"
       ln -fs ${script} node_modules/.bin
     done

pack.sh

@@ -63,6 +63,16 @@ for dir in $(find packages -name dist | grep -v node_modules | grep -v run-wrapp
   rsync -a $dir/ ${distdir}/
 done
 
+# Record the dependency order of NPM packages into a file
+# (This file will be opportunistically used during publishing)
+#
+# Manually sort 'aws-cdk' to the end, as the 'cdk init' command has implicit dependencies
+# on other packages (that should not appear in 'package.json' and so
+# there is no way to tell lerna about these).
+for dir in $(lerna ls --toposort -p | grep -v packages/aws-cdk) $PWD/packages/aws-cdk; do
+  (cd $dir/dist/js && ls >> ${distdir}/js/npm-publish-order.txt) || true
+done
+
 # Remove a JSII aggregate POM that may have snuk past
 rm -rf dist/java/software/amazon/jsii
 

package.json

@@ -18,9 +18,9 @@
     "fs-extra": "^9.1.0",
     "graceful-fs": "^4.2.6",
     "jest-junit": "^12.0.0",
-    "jsii-diff": "^1.23.0",
-    "jsii-pacmak": "^1.23.0",
-    "jsii-rosetta": "^1.23.0",
+    "jsii-diff": "^1.24.0",
+    "jsii-pacmak": "^1.24.0",
+    "jsii-rosetta": "^1.24.0",
     "lerna": "^3.22.1",
     "standard-version": "^9.1.1",
     "typescript": "~3.9.9"

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

@@ -165,6 +165,7 @@ export class AppMeshExtension extends ServiceExtension {
 
         'me-south-1': this.accountIdForRegion('me-south-1'),
         'ap-east-1': this.accountIdForRegion('ap-east-1'),
+        'af-south-1': this.accountIdForRegion('af-south-1'),
       },
     });
 
@@ -346,7 +347,7 @@ export class AppMeshExtension extends ServiceExtension {
     // Next update the app mesh config so that the local Envoy
     // proxy on this service knows how to route traffic to
     // nodes from the other service.
-    this.virtualNode.addBackend(otherAppMesh.virtualService);
+    this.virtualNode.addBackend(appmesh.Backend.virtualService(otherAppMesh.virtualService));
   }
 
   private routeSpec(weightedTargets: appmesh.WeightedTarget[], serviceName: string): appmesh.RouteSpec {