Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(aws-stepfunctions): support StateMachineType #5398

Merged
merged 1 commit into from
Dec 20, 2019
Merged

Conversation

wqzoww
Copy link
Contributor

@wqzoww wqzoww commented Dec 12, 2019

A new optional parameter StateMachineType has been introduced to the module of aws-stepfunctions by this commit.

  • The type of this variable is enum because only EXPRESS and STANDARD are acceptable.
  • The default value is STANDARD if users do not assign value to this field.

The corresponding comments and tests have been created as well.

Closes #5397


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

@wqzoww wqzoww requested a review from eladb as a code owner December 12, 2019 22:14
@mergify
Copy link
Contributor

mergify bot commented Dec 12, 2019

Thanks so much for taking the time to contribute to the AWS CDK ❤️

We will shortly assign someone to review this pull request and help get it
merged. In the meantime, please take a minute to make sure you follow this
checklist
:

  • PR title type(scope): text
    • type: fix, feat, refactor go into CHANGELOG, chore is hidden
    • scope: name of module without aws- or cdk- prefix or postfix (e.g. s3 instead of aws-s3-deployment)
    • text: use all lower-case, do not end with a period, do not include issue refs
  • PR Description
    • Rationale: describe rationale of change and approach taken
    • Issues: indicate issues fixed via: fixes #xxx or closes #xxx
    • Breaking?: last paragraph: BREAKING CHANGE: <describe what changed + link for details>
  • Testing
    • Unit test added. Prefer to add a new test rather than modify existing tests
    • CLI or init templates change? Re-run/add CLI integration tests
  • Documentation
    • README: update module README to describe new features
    • API docs: public APIs must be documented. Copy from official AWS docs when possible
    • Design: for significant features, follow design process

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: FAILED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: FAILED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws aws deleted a comment from mergify bot Dec 16, 2019
@aws aws deleted a comment from mergify bot Dec 16, 2019
@aws aws deleted a comment from mergify bot Dec 16, 2019
@aws aws deleted a comment from mergify bot Dec 16, 2019
@aws aws deleted a comment from mergify bot Dec 16, 2019
@aws aws deleted a comment from mergify bot Dec 16, 2019
@@ -98,8 +130,11 @@ export class StateMachine extends StateMachineBase {
const graph = new StateGraph(props.definition.startState, `State Machine ${id} definition`);
graph.timeout = props.timeout;

this.stateMachineType = props.stateMachineType ? props.stateMachineType : StateMachineType.STANDARD;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the default in CloudFormation perhaps STANDARD? I think so, no? If so, I'd rather we default to undefined here, so that the churn on the existing CloudFormation templates is minimal.

The @default annotation on the stateMachineType property should STILL indicate that the default behavior is STANDARD. @default annotations concern themselves with behavior of the stack as a whole, not with the details of what is rendered to a CFN temlate.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your feedback.

In my latest commit, the member variable stateMachineType is set to STANDARD by default (line 133), while the parameter stateMachineType in the cloudformation resource keeps undefined if users do not specify this optional field.

This solution helps avoid breaking the existing integration tests. :)

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: FAILED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

import { Test } from 'nodeunit';
import stepfunctions = require('../lib');

export = {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also added unit tests to cover different scenarios regarding stateMachineType.

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify
Copy link
Contributor

mergify bot commented Dec 20, 2019

Thank you for contributing! Your pull request is now being automatically merged.

@mergify mergify bot merged commit ea095f0 into aws:master Dec 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

aws-stepfunctions: support StateMachineType
3 participants