aws-samples/aws-cdk-intro-workshop

Introduction to the AWS CDK - Workshop

Introduction to the AWS Cloud Development Kit (CDK) - Workshop

Developer Guide

This workshop is built with markdown as a static HTML site using hugo.

Installing Hugo

Because we use asset pipelines and some integrity stamping techniques, we need the "extended" edition. (This is the recommended version by Hugo themselves, but it's worth pointing out.)

On MacOS, you can install it straight from Brew:

$ brew install hugo

There are installation instructions available from the Hugo documentation, however the short form is "Download the latest extended version from the releases page and put the binary in your PATH somewhere".

All else fails, follow the installation instructions. As long as you have the Extended hugo release, it's all good.

Theme

This is built off the Hugo-Book theme, lightly modified to suit our needs. A point of note is that this Should eventually be moved to a git submodule, but there's changes that need to be upstreamed.

Notably:

• Upstream does not use any Subresource Integrity checking. This is done out of paranoia
• Upstream still has a small handful of inline styles (which I've worked hard to remove)

Building locally

You'll find the content of the workshop in the workshop/ directory.

You can start up a local development server by running:

$ cd workshop
$ hugo serve 

open http://localhost:1313/ and you'll have the workshop as it stands.

Adding translations & localization.

Adding a translation means

• Copying the content from workshop/content/en/ into your own directory (workshop/content/xx)
• Translating the content
• Adding a configuration for your language in workshop/config.toml
• Adding a translation file for all appropriate legal terms in the workshop/i18n/xx.yml file, copied from en.yml

The last part is important! We need to have a translation for

• "Privacy", "Site Terms"

And we Should have a translation for

• The cookie banner message
• the cookie banner actions.

These will fall back to the English ones (such as in the JP one) and the link will go to the appropriate-enough regional terms and privacy pages.

If your language needs special fonts in order to render correctly, you should add them in the localization file. For example, the Japanese localization uses Noto Sans JP to make sure that the typography looks good, as well as using two fixed-width typefaces (Nanum Gothic Coding and M PLUS Rounded 1c) in order to make the mixed English-Japanese legible for everyone.

- id: fontUrl
  translation: "https://fonts.googleapis.com/css2?family=Nanum+Gothic+Coding:wght@400;700&family=M+PLUS+Rounded+1c:wght@400;500;700&family=Noto+Sans+JP:wght@400;500;700&display=swap"
- id: bodyFontFamily
  translation: "'Noto Sans JP', sans-serif"
- id: headingFontFamily
  translation: "'Noto Sans JP', sans-serif"
- id: codeFontFamily
  translation: "'Nanum Gothic Coding' 'M PLUS Rounded 1c', monospace"

There must be some backup font included -- The stylesheet will not provide one for you. As a rule of thumb, Noto makes a good option for most languages, with sans-serif falling back on whatever the browser can provide most efficiently. Code fonts should be monospace.

If you can, you want at least the following weights:

• 400 (used for body text)
• 500 (used for for headlines)
• 700 (used for bold text)

Do not use "artsy" typefaces. According to AWS style guides, we should be using Ember, but the typeface isn't cleared for hosting on GitHub. Until then, we'll use Noto Sans as a default where reasonable.

The use of serifed headlines is allowed if the language expects it. Chinese is monotonous to read when only presented in "sans". To give a clean distinction between headline and body, CJK languages or any language which "prefers" a certain type of headline may opt to use a "serif" (read: alternate style) headline typeface.

When in doubt, ask a native speaker and look to examples of type in that language (technical books, newspapers, etc are good starts) to find guidance in what historically separates headline text from the body text. AWS customers (and employees!) come from all around the world, and this is intended to cater to them.

Website Infrastructure

The workshop is available at https://cdkworkshop.com. It's a static website hosted on S3 and served through CloudFront.

It is implemented as a (surprise) CDK application under the cdkworkshop.com directory.

• npm install - bootstrap.
• npm run build and npm run watch
• npm run deploy - build & deploy

Auto-deployment

You shouldn't have to manually deploy: Any commit merged into main should cause the site to self-deploy via CodeBuild.

License Summary

This sample code is made available under a modified MIT license. See the LICENSE file.

aws-cdk-intro-workshop's Issues

.NET version of the workshop producing NuGet package version mismatches

🐛 Bug Report

What is the problem?

.NET version of the workshop has several "dotnet add package Amazon.CDK.xxxx" instructions, which may result in project build failures if CDK CLI is not of the latest version. .NET workshop instructions need to be updated to ensure that CLI CDK version is used when adding CDK NuGet packages to the sample project.

Reproduction Steps

• Install old version of the CDK CLI.
• Follow instructions of the .NET Workshop, specifically where participants are asked to add CDK NuGet packages using "dotnet add package Amazon.CDK.xxxx" instructions.
• Check the .csproj file content: observe pre-existing CDK NuGet reference being of the CLI version, while the just-added one(s) being of the latest CDK library version available at NuGet.org.
• Attempt to build, observe failures, usually involving JSII.

Environment

• CDK CLI Version: 1.31
• Section: http://localhost:1313/40-dotnet/30-hello-cdk/200-lambda.html#install-the-aws-lambda-construct-library
• Language: .NET/C#

error using cdk-dynamo-table-viewer

🐛 Bug Report

What is the problem?

error while installing cdk-dynamo-table-viewer and unable to cdk diff later

Reproduction Steps

source .env/bin/activate

pip install dk-dynamo-table-viewer

cdk diff

Verbose Log

aws-cdk-region-info 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-cx-api 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-core 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-ssm 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-sqs 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-sns 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-sns-subscriptions 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-s3 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-s3-assets 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-route53 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-logs 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-lambda 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-kms 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-iam 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-events 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-elasticloadbalancingv2 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-ec2 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-dynamodb 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-cloudwatch 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-cloudformation 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-certificatemanager 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-autoscaling-common 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-applicationautoscaling 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-aws-apigateway 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
aws-cdk-assets 1.20.0 has requirement jsii~=0.21.1, but you'll have jsii 0.20.11 which is incompatible.
Installing collected packages: jsii, cdk-dynamo-table-viewer
  Found existing installation: jsii 0.21.1
    Uninstalling jsii-0.21.1:
      Successfully uninstalled jsii-0.21.1
Successfully installed cdk-dynamo-table-viewer-3.1.0 jsii-0.20.11

Environment

• CDK CLI Version: 1.20.0 (build 021c521)
• Section: USING CONSTRUCT LIBRARIES
• Browser: all
• Language: Python

Other information

No instructions to tear down DynamoDB (during cleanup)

At the end of the workshop when we tear down the stack there are no instructions to delete DynamoDB. Folks using dev environments could potentially incur costs as a result. Might be a good idea to remind folks to wipe DynamoDB after they do cdk destroy.

DynamoTableViewer requires update

🐛 Bug Report

Eladb.DyanmoTableViewer needs some updates:

• Dependency on Amazon.JSII.Runtime < 0.21.0 (for 3.0.6, and < 0.22.0 for 3.1.2). All the other CDK packages depend on Amazon.JSII.Runtime > 1.9.0.
• Doesn’t have the update to use Node 12 on Lambda, and still references Node 8, which is no longer supported.
• Specifically calls out old version of package to use as dependency

Cognito user pool + APIGW + Lambdas

❓ Guidance Question

The Question

Is it possible to get a step by step example for how to set up an APIGW so it uses specific Cognito user pools for specific URLs?

Similar to this question on stackoverflow.

Environment

• CDK CLI Version: 1.19.0 (build 5597bbe)
• Section: n/a
• Browser: all
• Language: all | Python

Other information

The idea is to have a working set of Cognito user pools.
These should then be used as Authorizers for a set of API GW Rest APIs that trigger lambdas.
The example should explain how to create the authorizers properly.
The example should also explain how to make use of the tokens within lambda.

docs: Move TypeScript stop 'watch' to cleanup steps

🚀 Feature Request

General Information

• 👋 I may be able to implement this feature request

• ⚠️ This feature might incur a breaking change

Description

In the workshop documentation for the TypeScript project, the user is told to stop the npm run watch command after completing /workshop/content/20-typescript/50-table-viewer/400-expose-table.md. However, this makes it impossible to complete the "Extra credit" two steps later because changes to the TypeScript files will not be converted to their JavaScript version.

Stopping the watch should be part of the Clean Up operations at the end of the workshop.

Proposed Solution

Move the phrase:

We’re finished making code changes, so once you save this file, you can close the npm run watch command with Ctrl-C.

from /workshop/content/20-typescript/50-table-viewer/400-expose-table.md
to /workshop/content/20-typescript/60-cleanups.md

Environment

• CDK CLI Version: 1.19.0 (build 5597bbe)
• Section: [ AWS CDK Intro Workshop > TypeScript Workshop > Using construct libraries > Exposing our hit counter table ]
• Browser: Chrome
• Language: TypeScript

Other information

Update gitter link

The link to gitter on the side nav bar currently points to the github repo for CDK. It should instead be:

https://gitter.im/awslabs/aws-cdk

Various small improvements to the CDK Workshop

🚀 Feature Request

General Information

• 👋 I may be able to implement this feature request

• ⚠️ This feature might incur a breaking change

Description

There are a few typos, outdated screenshots, notes to be added, broken links and text to be reworded.

Proposed Solution

• Fix typos

• Replace outdated screenshots with new screenshots

• Add some notes to make things clearer

• Replace broken links with working links

• Reword some text to make things clearer

Environment

N/A

Other information

Indentation is missing in "Lambda handler code" of "Hello Lambda"

🐛 Bug Report

What is the problem?

• Indentation is missing in "Lambda handler code" of "Hello Lambda"
  • Link: https://cdkworkshop.com/20-typescript/30-hello-cdk/200-lambda.html

• Indentation is present in "Cleaup sample" though
  • Link: https://cdkworkshop.com/20-typescript/30-hello-cdk/100-cleanup.html

Reproduction Steps

Visit https://cdkworkshop.com/20-typescript/30-hello-cdk/200-lambda.html

Verbose Log

N/A

Environment

N/A

Other information

Syntax error in DynamoDB example.

🐛 Bug Report

What is the problem?

Section Exposing our hit counter table has a syntax error:

    const table = new dynamodb.Table(this, 'Hits', { 
      name: 'path', 
      type: dynamodb.AttributeType.STRING
    });

These are not the correct properties, should be wrapped in partitionKey: {}

cdkworkshop.com not updating

🐛 Bug Report

What is the problem?

The https://cdkworkshop.com site is not updating. It does not match the contents of this repo. This is especially notable with the Python examples which remain incorrect and out of date (fixed in #99). Is the site not being rebuilt/updated?

Reproduction Steps

Visit https://cdkworkshop.com/40-dotnet/30-hello-cdk/300-apigw.html which should have the fix from 055f5c4 (#97) on the page. It does not.

Visit https://cdkworkshop.com/30-python/20-create-project/300-structure.html which should have the fixes from #99 on the page. It does not.

Verbose Log

Environment

• CDK CLI Version:
• Section:
• Browser:
• Language:

Other information

AWS CDK Python Workshop (sample-app) Broken & Out of Sync

🐛 Bug Report

What is the problem?

I am new to the CDK, so I figured following the workshop at cdkworkshop.com would be my best bet to learning how to use it. I tried to follow the python tutorial, but it is so out of sync that it is unusable at this point. There are syntax errors that get created by following the steps provided, and even when I came up with workarounds to avoid those, the cdk will fail to synth because of an error in the aws-cdk codebase.

Reproduction Steps

The first issue I noticed is with the naming of the project directory as recommended by the tutorial. It says to do it like so:

By following this step, I am able to initialize the sample-app, start the created virtualenv and install the requirements, but once I get to the point where I should be able to run cdk synth, it fails because of a syntax error in the code:

Since this is directly due to the directory being created with a hyphen, my simple suggestion here would be to rename the directory in the workshop (eg. cdkWorkshop, cdk_workshop, cdkworkshop, etc.).

I then tried to restart the workshop with a new directory name (cdkws). I was able to get to the same spot in the tutorial, at which point I found multiple discrepancies in what I had via the sample-app vs. what was on the workshop site.

1. app.py
   From the workshop:

From the downloaded sample-app:

The naming difference is fine (it looks as though it used to always default to 'hello' for the stack code and it now is based on directory name), but a whole stack is missing in the sample-app?

2. xx_stack.py
   workshop:

sample-app:

HelloConstruct is not even imported in the sample-app (nor is it a file in anywhere in the project), and there's multiple missing lines of code.

Even ignoring these issues, when I try to run cdk synth or cdk ls to continue with the workshop, it fails, this time for another reason:

All 'cdk' commands, including running pytest fail with this same exact issue.

Any reason why this is so out of sync and broken? Are there expected updates to fix these issues? I would love to follow the tutorial but it's unusable at this point. I'm happy to provide more info if needed.

Environment

• CDK CLI Version: 1.18.0 (build bc924bc)
• Section: Python Workshop/New Project
• Browser: Chrome 78.0.3904.108
• Language: Python 3.7.5

Add github (feedback) link in the workshop

Cleanup TS

🚀 Feature Request

In the TS cleanup step one should mention that cdk destroy does not clean up everything, for example, the DynamoDB table, the S3 bucket, and the CDKToolkit CFN stack are still left over after the command has completed.

"Prerequisites" section unclear

🐛 Bug Report

What is the problem?

There is potential for confusion with the "Prerequisites" section specific to each language (it could seen to be skippable and the user could jump straight into the language workshop).

Syntax issue with the hello_stack.py provided in HitCounter Example

🐛 Bug Report

What is the problem?

The code has syntax issues

Reproduction Steps

$ cdk deploy hello-cdk-1

Traceback (most recent call last):
File "app.py", line 5, in
from aws_cdk import(core, aws_lambda as _lambda, aws_dynamodb as ddb, core, )
from hello.hello_stack import MyStack
File "/root/cdk-workshop/hello/hello_stack.py", line 3, in
from hitcounter import HitCounter
ModuleNotFoundError: No module named 'hitcounter'

Current code :
from hitcounter import HitCounter

Expected code:
from .hitcounter import HitCounter

$ cdk diff hello-cdk-1
Traceback (most recent call last):
File "app.py", line 9, in
MyStack(app, "hello-cdk-1", env={'region': 'us-east-2'})
File "/usr/local/lib/python3.7/site-packages/jsii/_runtime.py", line 66, in call
inst = super().call(*args, **kwargs)
File "/root/cdk-workshop/hello/hello_stack.py", line 14, in init
apigw.LambdaRestApi(self, 'APIEndpoint',handler=hello_with_counter.handler)
AttributeError: 'HitCounter' object has no attribute 'handler'

Current code :
apigw.LambdaRestApi(self, 'Endpoint',handler=hello_with_counter.handler,)

Expected code:
apigw.LambdaRestApi(self, 'Endpoint',handler=hello_with_counter._handler,)

Typo in the Typescript Workshop

🐛 Bug Report

What is the problem?

There is a typo in https://cdkworkshop.com/20-typescript/40-hit-counter/100-api.html.

The following description is a bit unclear.

'AWS CDK Reference' link at end of cdkworkshop.com page gives a 404 error

🐛 Bug Report

What is the problem?

Trying to follow the link for 'AWS CDK Reference' at the end of the main page on https://cdkworkshop.com/ gives a 404 Error.

The current link is https://awslabs.github.io/aws-cdk/

Other information

Perhaps the link should be https://docs.aws.amazon.com/cdk/api/latest/docs/aws-construct-library.html

mvn needs a clean after deleting test directory

🐛 Bug Report

What is the problem?

On the "Delete the sample code from your stack" page for Java, the mvn package command doesn't work because, while the src/test/ dir is gone, the compiled test is still in target/.

Reproduction Steps

Follow the workshop up to this point.

Fix:

• mvn clean package gets rid of the compiled test.
• Alternatively, the instruction to delete the src/test/ tree could be moved to before the first mvn package in the workshop.

Environment

• CDK CLI Version: 1.36.1 (build 4df7dac)
• Section: Delete the sample code from your stack
• Language: Java(TM) SE Runtime Environment (build 9.0.4+11), Apache Maven 3.6.3

Typoes HitCounterHandler should be HitCountHandler, and hitcounter.handler should be hitcount.handler in hitcounter.py

What is the problem?
The code has typoes

Typoes in https://cdkworkshop.com/30-python/40-hit-counter/600-permissions.html

File "hitcounter.py", line22
Current code :
HitCounterHandler

Expected code:
HitCountHandler

File "hitcounter.py", line24
Current code :
hitcounter.handler

Expected code:
fhitcount.handler

This is a documentation issue

TypeScript: Fine-Grained Assertion Tests HitCounter 'DynamoDB Table Created' test missing lambda import

🐛 Bug Report

What is the problem?

When following the instructions on ASSERTION TESTS for the TypeScript workshop the first time you run npm run build && npx jest it fails, reporting Cannot find name 'lambda'.

Reproduction Steps

Copy hitcounter.test.ts code from workshop
Run npm run build && npx jest

Verbose Log

cdk-workshop git:(master) ✗ npm run build && npx jest

[email protected] build /cdk-workshop
tsc

test/hitcounter.test.ts:9:26 - error TS2304: Cannot find name 'lambda'.

9 downstream: new lambda.Function(stack, 'TestFunction', {
~~~~~~
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! [email protected] build: tsc
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the [email protected] build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:

Environment

• CDK CLI Version: 1.51.0 (build 8c2d53c)
• Section: Fine-Grained Assertion Tests
• Browser: N/A
• Language: TypeScript

Other information

Including
import * as lambda from '@aws-cdk/aws-lambda'; during the imports appears to solve the problem

Use newer version of cdk-dynamo-table-viewer

When going through the CDK workshop, I noticed the referenced version of cdk-dynamo-table-viewer (3.0.2) has an earlier release of the CDK core, which causes compilation issues when going through this workshop with the newest version (1.0.0) of the CDK core. Here's the page where the npm install command is mentioned:

https://cdkworkshop.com/20-typescript/50-table-viewer/200-install.html

For me, using 3.0.5 of the table viewer made this issue go away:

npm install [email protected]

Video intro

When delivering the workshop, and presenting the included deck - it gives a nice overview, and shows people the expected outcome.

For people discovering the workshop themselves, they don't get this. It would be good to record a 10min cut-down version of the deck and have it on the homepage.

Workshop (Python) should advise about RetentionPolicy

_Originally posted by @telenieko in aws/aws-cdk#7403

Hi,

I just got bit by #3476, it is stated that this is intentional and documented but...

Given it's a workshop, one would expect that the last step would destroy all created resources, which does not happen and there's no warning about it.

The Workshop should either:

In the Congrats page, when telling you to cdk destroy advise that the DynamoDB table will not be deleted (extra points for a link to the RetentionPolicy docs)
When creating the table, set removalPolicy: RemovalPolicy.DESTROY and explain it
Option two would be preferable as it explains something quite useful.

ES6 imports on lambda assets

The live version is still broken.

#125

Typo: Type changes in typescript/hit-counter

🐛 Bug Report

What is the problem?

In the Typescript/Hit Counter the type of downstream is lambda.IFunction at the start of the exercise and lambda.Function later.

20-typescript/40-hit-counter/100-api.html

export interface HitCounterProps {
  /** the function for which we want to count url hits **/
  downstream: lambda.IFunction;
}

in 20-typescript/40-hit-counter/300-resources.html

export interface HitCounterProps {
  /** the function for which we want to count url hits **/
  downstream: lambda.Function;
}

I'm new to typescript, sorry if this isn't a typo.

Reproduction Steps

Verbose Log

Environment

Other information

In TypeScript project, 'noUnusedLocals' is not enabled

🐛 Bug Report

What is the problem?

https://github.com/aws-samples/aws-cdk-intro-workshop/blob/master/workshop/content/20-typescript/30-hello-cdk/200-lambda.md states the following:

Once you save cdk-workshop-stack.ts, you should see an error message in the npm run watch window that hello is declared but never use. Cool huh?

However, you will not receive that error message because the in the tsconfig.json that is shipped with the project, the noUnusedLocals compilerOptions are set to false.

This is very confusing for people executing the tutorial because they are told that they will be receiving output that they do not.

Reproduction Steps

Execute the TypeScript project, exactly as stated, up through the "Add an AWS Lambda Function to your stack" section of [ AWS CDK Intro Workshop > TypeScript Workshop > Hello, CDK! > Hello Lambda ]

Verbose Log

Environment

• CDK CLI Version:
• Section: [ AWS CDK Intro Workshop > TypeScript Workshop > Hello, CDK! > Hello Lambda ]
• Browser: Chrome
• Language: TypeScript

Other information

To fix this inconsistency, either:

1. Set noUnusedLocals to true in the compilerOptions section of tsconfig.json
2. or Remove the statement in the tutorial that claims you will receive the error message about unused variables.

Have lambda functions in workshop use same language as the workshop itself

🚀 Feature Request

General Information

Currently, all lambda functions used in the workshop are authored in Javascript, but the
workshop would be more impactful if those Lambdas were written in the same language
as the infrastructure code.

Documentation bugs for the python cdk workshop

🐛 Bug Report

What is the problem?

The workshop for python has some small syntactic issues that causes the cdk demo to fail

Reproduction Steps

Follow the steps verbatim(do not copy and paste like the document suggests).

Verbose Log

Not really a version log statement

Environment

Documentation bugs but using Chrome(it is just not clear documentation).

Other information

npm run watch does not trigger an error for unused variable

🐛 Bug Report

What is the problem?

https://cdkworkshop.com/20-typescript/30-hello-cdk/200-lambda.html

Mentions this:
Once you save cdk-workshop-stack.ts, you should see an error message in the npm run watch window that hello is declared but never use. Cool huh?

Which is no longer accurate. IDE will still give this feedback though.

Minor Typo in https://cdkworkshop.com/40-dotnet/50-table-viewer/400-expose-table.html

🐛 Bug Report

What is the problem?

In the code to modify for HitCounter.cs the property is named MyTable but the code added to the constructor has Table = table; Should be MyTable = table;

missing path of hitcount.handler

🐛 Bug Report

The sample code of hitcounter.py line 24
handler='hitcount.handler',
should be:
handler='lambda/hitcount.handler',

otherwise can't locate hitcount module.

Java Workshop

🚀 Feature Request

General Information

• 👋 I may be able to implement this feature request

• ⚠️ This feature might incur a breaking change

Description

We should implement a Java version of the workshop procedure to match GA languages for CDK

CDK does not pull same versions for modules but only the latest

🐛 Bug Report

What is the problem?

I did the CDK tutorial and installed in the first step libraries with version 1.45.0. Then, I got an compilation error. The reason was that I added AWS Lambda and it was automatically version 1.47.0 which is incompatible with the other 1.45.0 libraries.

I solved it by up executing:
$ npm install -g npm-check-updates
$ ncu -u
$ npm install

Reproduction Steps

Install CDK dependencies with 1.45.0. Then, install AWS Lambda CDK. It will be automaticall version 1.47.0. Then add a Lambda construct. You will get an complication error.

Environment

• CDK CLI Version: 1.45.0
• Section: Hello Lambda
• Browser: Chrome
• Language: TypeScript

Explore gatsbyjs instead of hugo for building website?

🚀 Feature Request

General Information

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

Description

• First of all, thank you for setting up this amazing website https://cdkworkshop.com for helping people learn about CDK. We're considering doing similar tutorials for aws-sdk-js-v3-workshop after v3 goes GA
• As per your developer guide, your website is built in hugo which is written in golang. I noticed that aws-cdk itself is written in TypeScript/JavaScript. I was wondering if you'd explored something JavaScripty like GatsbyJS for building website for this workshop.

Proposed Solution

Explore something JavaScripty like GatsbyJS for building website for this workshop.

Environment

N/A

Other information

N/A

404 on conclusion page

This link 404's:
https://github.com/awslabs/aws-cdk/tree/master/examples

On this page:
https://cdkworkshop.com/70-conclusion.html

Issue with CdkWorkshop typescript

🐛 Bug Report

What is the problem?

Workshop url: https://cdkworkshop.com/20-typescript/40-hit-counter/200-handler.html

The Typescript CdkWorkshop uses the following import statement:

// file: lambda/hitcounter.js
import { DynamoDB, Lambda } from 'aws-sdk';

However, this produces the following error (from the deployed lambda): See Verbose log
I googled the error and found the following stackoverflow page:
https://stackoverflow.com/questions/56859727/why-do-i-get-a-usercodesyntaxerror-when-i-have-no-syntax-error-in-my-code

The guide uses an ES6 style import, which is not supported by the aws node.js 10.x runtime. I changed it to a standard module require syntax and the function worked as expected.

Reproduction Steps

cdk deploy with the lambda/hitcounter.js file and look in the cloudwatch logs

Verbose Log

2020-02-16T12:47:27.490Z	undefined	ERROR	Uncaught Exception
{"errorType":"Runtime.UserCodeSyntaxError","errorMessage":"SyntaxError: Unexpected token {","stack":["Runtime.UserCodeSyntaxError: SyntaxError: Unexpected token {","    
at _loadUserApp (/var/runtime/UserFunction.js:98:13)","    
at Object.module.exports.load (/var/runtime/UserFunction.js:140:17)","    
at Object.<anonymous> (/var/runtime/index.js:45:30)","    
at Module._compile (internal/modules/cjs/loader.js:778:30)","    
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)","    
at Module.load (internal/modules/cjs/loader.js:653:32)","    
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)","    
at Function.Module._load (internal/modules/cjs/loader.js:585:3)","    
at Function.Module.runMain (internal/modules/cjs/loader.js:831:12)","    
at startup (internal/bootstrap/node.js:283:19)"]}

Environment

• CDK CLI Version: 1.23.0 (build 01f326e)
• Section: https://cdkworkshop.com/20-typescript/40-hit-counter/200-handler.html
• Browser: Firefox
• Language: TypeScript

Other information

Small error in CDK Workshop Code?

🐛 Bug Report

What is the problem?

Reproduction Steps

Verbose Log

Environment

• CDK CLI Version:
• Section:
• Browser:
• Language:

Other information

In python workshop, there is a problem.

🐛 Bug Report

What is the problem?

In "Writing Constructs" part, there is "Use the hit counter" section.

I typed "from hitcounter import HitCounter" in my cdkworkshop_stack.py, but when I did sdk deploy command. It couldn't find hitcounter module. So I changed from .hitcounter import Hitcounter and It was fixed. I think you need to check if it's okay or not.

Reproduction Steps

Verbose Log

Environment

• CDK CLI Version: 1.39.0
• Section: visual code
• Browser: Chrome
• Language: Python

Other information

Windows installation steps wrong

When installing the CDK, the workshop recommends you install the CDK as Administrator on Windows.

Windows: you’ll need to run this as an Administrator

source: https://cdkworkshop.com/15-prerequisites/500-toolkit.html

This is incorrect - npm should be run as their normal user, otherwise the %PATH% does not get setup correctly, and cdk can't be run.

"jsii.errors.JSIIError: this.handler.addPermission is not a function" when deploying

🐛 Bug Report

What is the problem?

In the step Deploy in the page https://cdkworkshop.com/30-python/40-hit-counter/400-use.html the following error appears making the progress of the workshop impossible:

jsii.errors.JSIIError: this.handler.addPermission is not a function

Reproduction Steps

Follow the workshop using Python 3.7.5 and NodeJS 12.14.0

Verbose Log

jsii.errors.JavaScriptError:
  TypeError: this.handler.addPermission is not a function
      at LambdaIntegration.bind (/private/var/folders/mx/g17hdwqx645gwbzh5_cfp4p40000gq/T/jsii-kernel-rL9mAe/node_modules/@aws-cdk/aws-apigateway/lib/integrations/lambda.js:30:22)
      at Method.renderIntegration (/private/var/folders/mx/g17hdwqx645gwbzh5_cfp4p40000gq/T/jsii-kernel-rL9mAe/node_modules/@aws-cdk/aws-apigateway/lib/method.js:75:21)
      at Method.renderIntegration (/private/var/folders/mx/g17hdwqx645gwbzh5_cfp4p40000gq/T/jsii-kernel-rL9mAe/node_modules/@aws-cdk/aws-apigateway/lib/method.js:70:29)
      at new Method (/private/var/folders/mx/g17hdwqx645gwbzh5_cfp4p40000gq/T/jsii-kernel-rL9mAe/node_modules/@aws-cdk/aws-apigateway/lib/method.js:27:31)
      at RootResource.addMethod (/private/var/folders/mx/g17hdwqx645gwbzh5_cfp4p40000gq/T/jsii-kernel-rL9mAe/node_modules/@aws-cdk/aws-apigateway/lib/resource.js:17:16)
      at ProxyResource.addMethod (/private/var/folders/mx/g17hdwqx645gwbzh5_cfp4p40000gq/T/jsii-kernel-rL9mAe/node_modules/@aws-cdk/aws-apigateway/lib/resource.js:218:37)
      at new ProxyResource (/private/var/folders/mx/g17hdwqx645gwbzh5_cfp4p40000gq/T/jsii-kernel-rL9mAe/node_modules/@aws-cdk/aws-apigateway/lib/resource.js:209:35)
      at RootResource.addProxy (/private/var/folders/mx/g17hdwqx645gwbzh5_cfp4p40000gq/T/jsii-kernel-rL9mAe/node_modules/@aws-cdk/aws-apigateway/lib/resource.js:20:16)
      at new LambdaRestApi (/private/var/folders/mx/g17hdwqx645gwbzh5_cfp4p40000gq/T/jsii-kernel-rL9mAe/node_modules/@aws-cdk/aws-apigateway/lib/lambda-api.js:19:23)
      at Kernel._wrapSandboxCode (/Users/rajish/proj/cdkworkshop/.env/lib/python3.7/site-packages/jsii/_embedded/jsii/jsii-runtime.js:8224:19)
      at Kernel._create (/Users/rajish/proj/cdkworkshop/.env/lib/python3.7/site-packages/jsii/_embedded/jsii/jsii-runtime.js:7761:26)
      at Kernel.create (/Users/rajish/proj/cdkworkshop/.env/lib/python3.7/site-packages/jsii/_embedded/jsii/jsii-runtime.js:7508:21)
      at KernelHost.processRequest (/Users/rajish/proj/cdkworkshop/.env/lib/python3.7/site-packages/jsii/_embedded/jsii/jsii-runtime.js:7296:28)
      at KernelHost.run (/Users/rajish/proj/cdkworkshop/.env/lib/python3.7/site-packages/jsii/_embedded/jsii/jsii-runtime.js:7236:14)
      at Immediate._onImmediate (/Users/rajish/proj/cdkworkshop/.env/lib/python3.7/site-packages/jsii/_embedded/jsii/jsii-runtime.js:7239:37)
      at processImmediate (internal/timers.js:439:21)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "app.py", line 9, in <module>
    CdkworkshopStack(app, "cdkworkshop", env={'region': 'us-west-2'})
  File "/Users/rajish/proj/cdkworkshop/.env/lib/python3.7/site-packages/jsii/_runtime.py", line 66, in __call__
    inst = super().__call__(*args, **kwargs)
  File "/Users/rajish/proj/cdkworkshop/cdkworkshop/cdkworkshop_stack.py", line 29, in __init__
    handler=hello_with_counter,
  File "/Users/rajish/proj/cdkworkshop/.env/lib/python3.7/site-packages/jsii/_runtime.py", line 66, in __call__
    inst = super().__call__(*args, **kwargs)
  File "/Users/rajish/proj/cdkworkshop/.env/lib/python3.7/site-packages/aws_cdk/aws_apigateway/__init__.py", line 14026, in __init__
    jsii.create(LambdaRestApi, self, [scope, id, props])
  File "/Users/rajish/proj/cdkworkshop/.env/lib/python3.7/site-packages/jsii/_kernel/__init__.py", line 229, in create
    interfaces=[iface.__jsii_type__ for iface in getattr(klass, "__jsii_ifaces__", [])],
  File "/Users/rajish/proj/cdkworkshop/.env/lib/python3.7/site-packages/jsii/_kernel/providers/process.py", line 333, in create
    return self._process.send(request, CreateResponse)
  File "/Users/rajish/proj/cdkworkshop/.env/lib/python3.7/site-packages/jsii/_kernel/providers/process.py", line 318, in send
    raise JSIIError(resp.error) from JavaScriptError(resp.stack)
jsii.errors.JSIIError: this.handler.addPermission is not a function

Environment

• CDK CLI Version: 1.19.0 (build 5597bbe)
• Section: AWS CDK Intro Workshop > Python Workshop > Writing constructs > Use the hit counter
• Browser: Chrome
• Language: Python

Inconsistency in project naming - Python path

🐛 Bug Report

What is the problem?

The project name set in the cdk init step is cdkworkshop while in other parts in text it's referred as hello or HelloWorld which causes confusion.

Environment

• CDK CLI Version: 1.19.0 (build 5597bbe)
• Section: all
• Browser: Chrome
• Language: Python

Add Python unit tests to cover new constructs

🚀 Feature Request

General Information

• 👋 I may be able to implement this feature request

• ⚠️ This feature might incur a breaking change

Description

After running cdk init sample-app --language python some very basic unit tests are created that cover the constructs in the sample app, but as the sample app is modified no tests are included to cover the additional constructs added in the later sections of the workshop. Testing is an important part of learning a new technology, and CDK should be no exception, so including some basic examples of how to test CDK constructs in Python would be helpful to users like me who learn best by example.

Proposed Solution

Add unit tests to cover the new constructs introduced as the user progresses through the workshop.

Environment

• CDK CLI Version: 1.22.0 (build 309ac1b)
• Section: Hello, CDK!, Writing constructs, Using construct libraries
• Browser: all
• Language: Python

Other information

Items found in review of Python version of CDK Workshop

Let me know if you'd like me to break these up into separate issues. It was easier to just track them in one place while doing the review. A couple of these aren't issues with the Workshop but rather things in the cdk tool.

0. Why don’t the code snippets have a light/dark toggle like in the Dev Guide? :-)
1. On Windows, the output of cdk init is full of terminal codes that would produce color and boldface on a linux system, but here make the output almost unreadable. Screen shot attached.

Not a problem in the Workshop per se of course. The color works fine when doing other things with the CDK, oddly.
2. Missing prerequisite: On Windows, Python needs to be installed so it’s on the PATH. Unfortunately, this is not the default! (It’s a checkbox on the first page of the Windows installer.) Without Python on the PATH, cdk init won’t create a virtualenv, which then throws off a lot of things...
3. I noticed that the cdk init output says that the CDK expects a Python executable named python3. The Windows Python installer does not install such an executable. Fortunately cdk init seems to work regardless as long as Python's on the path; however, this text should probably be changed. On Windows there’s a launcher called py that gets installed in C:\Windows so it’s guaranteed to be on the PATH. It is responsible for reading shebang lines from executed scripts (since Windows doesn’t do that natively) and launching the specified Python executable, among other things. So on Windows maybe just use that. Then you don’t have to worry about the interpreter being on the PATH.
4. The command given to activate the virtualenv on Windows uses the wrong slashes. Normally Windows is happy to use forward slashes in paths; however, when specifying an executable, it looks like you must use backslashes. .env\scripts\activate.bat will work.
5. I’m noticing that a lot of the cdk screenshots are a lot less colorful than the cdk actually is. Haas the cdk tool been upgraded recently to be more colorful? Maybe update the screen shots. :-) Whoops, those aren't screen shots. The syntax coloring should be turned off for those snippets, or else screen shots should be used if the color is important.
6. The API Gateway topic tells you to put some code in, but it doesn’t say which file it goes in. hello_stack.py is the last file you were working on in the previous topic and it does indeed go in there, but it would be nice to mention that.
7. In the Hit Counter Handler topic, the highlighted code (that indicates the lines you need to add to hitcounter.py) does not include the function definition for the handler() method (and its @property decorator), which does need to be added.
~~ 8. The Use The Hit Counter topic instructs you to open lib/cdk-workshop-stack.ts, which doesn’t exist in this Python project. It should be hello/hello_stack.py. ~~
9. Also, the imports in the new version of this code are in a different order than the original code you’re modifying. They work fine but it may throw readers off if their file is even slightly different from the one you think they have.
9. In the Cloudwatch Logs topic, users are instructed to click View On CloudWatch Logs, but the actual name of the button is View Logs in CloudWatch (it’s shown in the screen shot).
10. In Granting Permissions, you’re told to add the “highlighted lines” to hitcounter.py. There’s only one line highlighted. (Only one line is in fact needed; the plural in the text is wrong.)
11. At the end of the Test the Hit Counter topic, we’re told we’ll next consume a construct library published in npm. That's for Node.js; this should say PyPI.
12. In the Installing the Library topic, output is given for pip install command. There’s actually a lot more output; it should indicate that these are only the last two lines of the output (e.g. with an ellipsis).
13. In Add the Table Viewer to Your App topic, you’re told to edit lib/cdk-workshop-stack.ts. This should be hello/hello_stack.py.
14. In the Exposing Our Hit Counter Table topic, you’re told to edit hitcounter.ts. This should be hello/hitcounter.py.
15. The code in this topic changes table = ddb.Table( to self._table. Similarly, the ‘HITS_TABLE_NAME’ definition should be changed to self.table.table_name, and.table.grant_read_write_data needs to be changed to self.table. These changes are in the code but aren’t highlighted as changes. They should be highlighted so users know to make them.
16. The tip in the topic suggests holding down the Control or Command key and clicking on TableViewer to see the source code for its definition. This will depend on the editor you’re using, probably? Maybe say “in many editors (we use VS Code)” or something similar.
~~17. I noticed that when selecting text in the code blocks, the selection is invisible in Firefox. This is annoying. Also, selection works fine in dark mode in the CDK Dev Guide, so not sure why it doesn't work right here. (Works OK in Chrome and Edge, though.) ~~

Documentation code typo

In the workshop, on page / aliased link:

https://cdkworkshop.com/50-table-viewer/400-expose-table.html#now-we-can-access-the-table-from-our-stack the code sample has a typo that mismatches the constructor and super's arguments.

  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, name, props);

Node Runtime not supported anymore

🐛 Bug Report

What is the problem?

Node runtime_8_10 is not supported by Lambda anymore. Please update the same in the workshop.

Reproduction Steps

Verbose Log

const hello = new lambda.Function(this, 'HelloHandler', {
  runtime: lambda.Runtime.NODEJS_8_10,      // execution environment
  code: lambda.Code.asset('lambda'),  // code loaded from the "lambda" directory
  handler: 'hello.handler' 

https://cdkworkshop.com/20-typescript/30-hello-cdk/200-lambda.html
-->

Environment

• CDK CLI Version: 1.20.0
• Section: Hello Lambda
• Browser: all
• Language: Typescript

Other information

Stage not updated after switching functions

🐛 Bug Report

What is the problem?

I ran into a weird issue when completing the Typescript lab today. After introducing the hit counter function and deploying, the API Gateway stage ("prod") did not get updated, and it was still calling the original function. The weird part is that if I went to the API Gateway console and tested manually from the Resources node under the 'Endpoint' endpoint, it worked fine and called the new function.

Here: https://cdkworkshop.com/20-typescript/40-hit-counter/400-use.html

To fix it, I had to make a change to the API Gateway in the .ts file (I changed the name from Endpoint to HitCounterEndpoint, which I would recommend for the lab since it can be hard to pick out on the API Gateway console). When I deployed, the old broken gateway endpoint was destroyed and a new working one was created in its place.

Reproduction Steps

Not sure what I did differently to cause this. I had a few typos in the function that were causing it to fail before I got to the expected AccessDenied exceptions, but I fixed those and redeployed. I don't think they were related.

Verbose Log

Environment

• CDK CLI Version:
• Section:
• Browser:
• Language:

Other information

CDK synth give error stream closed error

🐛 Bug Report

What is the problem?

Dear Friends . I just did cdk init and then doing cdk synth and get the follwoing error

[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.6.0:java (default-cli) on project cdk-workshop: An exception occured while executing the Java class. Unable to send request to jsii-runtime: java.io.IOException: Stream closed -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.6.0:java (default-cli) on project cdk-workshop: An exception occured while executing the Java class. Unable to send request to jsii-runtime: java.io.IOException: Stream closed

I use java 8 . Need help to fix this issue

Reproduction Steps

do cdk-init --language= java then cdk synth

Verbose Log

cdk synth
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.6.0:java (default-cli) on project cdk-workshop: An exception occured while executing the Java class. Unable to send request to jsii-runtime: java.io.IOException: Stream closed -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.6.0:java (default-cli) on project cdk-workshop: An exception occured while executing the Java class. Unable to send request to jsii-runtime: java.io.IOException: Stream closed
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: org.apache.maven.plugin.MojoExecutionException: An exception occured while executing the Java class. Unable to send request to jsii-runtime: java.io.IOException: Stream closed
    at org.codehaus.mojo.exec.ExecJavaMojo.execute (ExecJavaMojo.java:339)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: software.amazon.jsii.JsiiException: Unable to send request to jsii-runtime: java.io.IOException: Stream closed
    at software.amazon.jsii.JsiiRuntime.requestResponse (JsiiRuntime.java:96)
    at software.amazon.jsii.JsiiClient.createObject (JsiiClient.java:82)
    at software.amazon.jsii.JsiiEngine.createNewObject (JsiiEngine.java:510)
    at software.amazon.awscdk.core.App.<init> (App.java:46)
    at com.myorg.CdkWorkshopApp.main (CdkWorkshopApp.java:7)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:282)
    at java.lang.Thread.run (Thread.java:748)
Caused by: java.io.IOException: Stream closed
    at java.lang.ProcessBuilder$NullOutputStream.write (ProcessBuilder.java:433)
    at java.io.OutputStream.write (OutputStream.java:116)
    at java.io.BufferedOutputStream.flushBuffer (BufferedOutputStream.java:82)
    at java.io.BufferedOutputStream.flush (BufferedOutputStream.java:140)
    at sun.nio.cs.StreamEncoder.implFlush (StreamEncoder.java:297)
    at sun.nio.cs.StreamEncoder.flush (StreamEncoder.java:141)
    at java.io.OutputStreamWriter.flush (OutputStreamWriter.java:229)
    at java.io.BufferedWriter.flush (BufferedWriter.java:254)
    at software.amazon.jsii.JsiiRuntime.requestResponse (JsiiRuntime.java:77)
    at software.amazon.jsii.JsiiClient.createObject (JsiiClient.java:82)
    at software.amazon.jsii.JsiiEngine.createNewObject (JsiiEngine.java:510)
    at software.amazon.awscdk.core.App.<init> (App.java:46)
    at com.myorg.CdkWorkshopApp.main (CdkWorkshopApp.java:7)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:282)
    at java.lang.Thread.run (Thread.java:748)
[ERROR] 
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
Subprocess exited with error 1

Environment

• **CDK CLI Version:1.19.0 (build 5597bbe)
• Section: java version 8
• Browser:
• Language:

Other information

Typos in CDK Typescript Workshop

🐛 Bug Report

What is the problem?

There are a few typos in the CDK TypeScript Workshop

Reproduction Steps

https://cdkworkshop.com/20-typescript/20-create-project/300-structure.html
https://cdkworkshop.com/20-typescript/40-hit-counter/500-logs.html

Verbose Log

N/A

Environment

• CDK CLI Version: N/A

• Section:
  New project -> Project structure
  Writing constructs -> CloudWatch Logs

• Browser: all

• Language: N/A

Other information

Mergify config is not proper yaml and is failing

🐛 Bug Report

What is the problem?

The mergify configuration is not proper yaml. This is causing the github check to fail.

Reproduction Steps

Submit any PR and watch the mergify step fail.

Verbose Log

Environment

Other information