basically wraps https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-ecs-patterns.ScheduledEc2Task.html or https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-ecs-patterns.ScheduledFargateTask.html

MVP construct schema:

task:
  provider: ec2, fargate
  ...

Default should be that it doesn't work / is not available. Add a flag: --allow-insecure. IIRC mu has this exact flag.

We might make it a list like --allow-insecure (allow all) and --allow-insecure cmd,other for a list of things to allow, etc...

This can be done in config.ts with a boolean flag so the preprocessor class does not add its cmd helper to Nunjucks.

stack deletion currently is a PITA. the manual process is explained here: https://stelligent.github.io/mutato/#/mutato-workflow?id=destroy

automate this.

We must have some sort of smoke testing to make sure constructs do actually what they are supposed to do. Emphasis on the database and storage constructs and their connection to the service construct.

Force push docs to gh-pages branch when they are built. We'll host them there.

See https://help.github.com/en/github/working-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site

There's no reason to use EIPs by default. Prove me wrong.

It could be changed here.
https://github.com/stelligent/mutato/blob/develop/lib/resources/network.ts#L32

Deploying the mutato-example-basic app.

Steps to reproduce:

1. Make changes to the index.html
2. commit changes, update github.
3. Branch triggers the Pipeline deployment.
4. Verify if changes to index.html by opening the Http endpoint in the CFN Output section.

The deployed version on each ECS Service are from the 1st successful deployment.

The Pipeline shows success on both stages. However, the CFN ChangeSets are failing. The submitted information didn't contain changes. Submit different information to create a change set.

Minor details that might be helpful.
1st deployment - original file without changes.
2nd deployment - added paragraph “The name is an x-files reference”
3rd deployment - added “3rd Deployment”
Here is repo I’m deploying.

In preparation for the blog post, I followed the steps in this gist to test a deployment of mutato's sample application. https://gist.github.com/mneil/e32dd411a44d4d0cac01b42de5841ef4

Here is the error from the Acceptance CFN deployment:

2020-04-06 10:02:49 UTC-0700 | networkacceptanceVPCPublicSubnet2SubnetB70416C7 | CREATE_FAILED | Template error: Fn::Select cannot select nonexistent value at index 1

2020-04-06 10:02:49 UTC-0700 | networkacceptanceVPCPrivateSubnet2Subnet6A11D49B | CREATE_FAILED | Template error: Fn::Select cannot select nonexistent value at index 1

Stack:arn:aws:cloudformation:us-east-1:324320755747:stack/Mutato-App-acceptance-scottnixonjr-mutato-example-basic-master/3fcc9ae0-7828-11ea-9956-0a1f955da693 is in ROLLBACK_COMPLETE state and can not be updated. (Service: AmazonCloudFormation; Status Code: 400; Error Code: ValidationError; Request ID: c54d08e7-346a-49d2-8dfd-3d4c353fdcca)

The CodeBuild process logs show this error message

Stack Mutato-App-acceptance-scottnixonjr-mutato-example-basic-master

User: arn:aws:sts::324320755747:assumed-role/Mutato-Pipeline-scottnixonjr-mut-buildRoleD55766F0-164PZ68Q754WL/AWSCodeBuild-e93bc96e-8c71-45c0-9b2f-0700fab3ba5a is not authorized to perform: cloudformation:GetTemplate on resource: arn:aws:cloudformation:us-east-1:324320755747:stack/Mutato-App-acceptance-scottnixonjr-mutato-example-basic-master/3fcc9ae0-7828-11ea-9956-0a1f955da693

we should be integrating with https://github.com/aws/jsii so mutato can be consumed on all platforms where CDK is supported

mkdocs?
typedoc?
sphinx?

Try them out, pick one, explain why it's the best and how we'll use it in a contribution guide (CONTRIBUTING.md). #15 covers actually setting it up. This is discovery and presentation for what we'll use.

I attempted to fix this in 20f68ee but it clearly did not work. Investigate?

following the generated-documentation PR, vscode is having a tough time properly inserting documentation tags for undocumented code. it appears that multiple engines are racing to insert docs on top of any undocumented code.

we previously had vscode set up to do formatOnSave. to reproduce the bug I am describing, create any piece of undocumented code, save the file and vscode inserts multiple jsdoc blocks.

please investigate this race condition at your own pace, this is not a priority.

it currently contains unnecessary commit data and junk files, hard reset the documentation branch with a clean state.

Source is riddled with assertions. These all should be converted to typed exceptions with tests against app.ts.

A lot of technical debt must be paid here.

The API docs that are auto generated are pathetic currently and it's mostly jsdoc2md's fault. LOTS of polish needs to be done here so it can be usable. Types must be added and more docs in the code level for constructs.

we can detect if the pipeline is missing registry credentials before pushing, do that so deploy fails faster.

there appears to be inconsistencies between what typedoc is configured to generate docs off of and what the linter is actually checking for. please have these read their configuration from a single place.

to reproduce this issue, add a private member to a class. this is excluded in typedoc, however linter returns a failure on its check. seems like eslint is ignoring the typedocOptions key under tsconfig.json

Unable to run mutato in a root account. Josue tried to run it in his personal account. The project tried to attach a webhook to Mutato but he is an admin.

Document that you need to be an admin of a repository in order to deploy it because you cannot setup a webhook in the repo when you create a github repo.

We should be using pinst to disable our postinstall script when the package is published as an npm dependency. The postinstall should not run for npm users.

similar to https://docs.drone.io/pipeline/conditions/

MVP construct schema:

storage:
  provider: s3, efs
  mount: /dev/whatever
  ...

Similar to the Mu convention (see contributing.md)
Post MVP?

post merging of the documentation PR, we are having a number of issues with the TS compiler and the general set up of the project. The one outstanding issue is coverage report. It is incorrect and inaccurate and seems to report random places as uncovered (maybe it has something to do with source maps). An audit pass should be done over TSC config and other toolings (esling, jsdoc, etc.)

Per MVP design docs, infra constructs (network, cluster, and cicd) can be either omitted from mu.yml or appear at most once. When provided in the shorthand version, this issue is automatically resolved due to the nature of json objects (two keys with the same name cannot coexist in the same object).

When provided in the explicit version, the following mu.yml should be rejected at the schema level:

mu:
  name1:
    type: cicd
    ...

  name2:
    type: cicd
    ...

basically wraps https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-ecs-patterns.ApplicationLoadBalancedEc2Service.html or https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-ecs-patterns.ApplicationLoadBalancedFargateService.html

MVP construct schema:

service:
  provider: ec2, fargate,
  ...

MVP construct schema:

database:
  provider: rds, aurora, serverless-aurora, dynamodb, docdb
  engine: mysql, postgresql, etc.
  ...

MVP construct schema:

cache:
  provider: redis, memcached
  ...

... so we can do conditional infra changes based on branches

getmu.io is for mu1.

getmu.io is in the prod account. We’ll want to borrow that domain.

basically wraps https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-ecs-patterns.QueueProcessingFargateService.html or https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-ecs-patterns.QueueProcessingEc2Service.html

MVP construct schema:

queue:
  provider: ec2, fargate
  ...

Currently in Mutato's AWS dev account, master branch is managing the release process to NPM and DockerHub.

This process is fine, but the way NPM package and Docker image are prepared must be polished:

• Docker image must be optimized to be as small as possible. Currently it's sitting at a whopping 500MB
• Container level (outside Container) testing must be conducted before a push to DockerHub
• NPM package must be tested before publish (through npm link command), I think the published package is currently not usable and it's just a source dump (? not sure. have not tested personally)