-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Moved the LambdaInvoke Action from the codepipeline module to the Lambda module #348
Conversation
Thanks for the new PR @eladb ! I just rebased and updated the PR. |
@@ -0,0 +1,90 @@ | |||
import { expect, haveResource } from '@aws-cdk/assert'; | |||
import { Pipeline, Stage } from '@aws-cdk/codepipeline'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nittiest of nits: When importing the same symbols (Stage
and Pipeline
in this case), sometimes we do import *
, other times we do import { ... }
. In both cases we only use Stage
and Pipeline
. We should try to be consistent unless there is a good reason for the exception.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mpiroc yes, you got me :) The reason for that is that I'm only moving existing tests, that were written before the Big L1-L2 Unification™. I changed it to use import * as ...
in the integ tests (which are meant to be similar to what a customer would write), but left the old way in the unit tests (in which it's less important I think). But, if you insist, I can change it in the unit tests as well :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mpiroc good point - I think we are standardizing around:
import foo = require('foo');
It's concise, namespaced, and fabulous 🎂
@skinny85 the build break is caused by a dependency cycle: I believe codecommit is only used as a test in lambda. Let's just rewrite this test not to include codecommit. Here's the output of
P.S. the other cycles are related to #32 |
Great catch @eladb , I would not guess a cycle might be the root cause of that. Alright, I'll change the integ test to not use |
… to its dedicated, new lambda-codepipeline module. This continues the refactoring of moving out concrete Action types from the codepipeline module.
Completely changed the approach. The dependencies right now look like this:
So, Because of that, I've extracted a separate Let me know if there are any objections to this approach. |
@@ -1,4 +1,7 @@ | |||
import { Stack } from '@aws-cdk/core'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rename to test.general-validation.ts
@@ -0,0 +1,21 @@ | |||
## AWS Lambda Construct Library for AWS CodePipeline Actions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The title should be AWS CodePipline Actions for AWS Lambda
😄
Example usage: | ||
|
||
```ts | ||
import * as codepipeline from '@aws-cdk/codepipeline'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use import codepipline = require('@aws-cdk/codepipeline')
(this is the style we eventually decided to use across the board).
```ts | ||
import * as codepipeline from '@aws-cdk/codepipeline'; | ||
import * as lambda from '@aws-cdk/lambda'; | ||
import * as lambda_codepipeline from '@aws-cdk/lambda-codepipeline'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No underscores in variable names.
{ | ||
"name": "@aws-cdk/lambda-codepipeline", | ||
"version": "0.7.3-beta", | ||
"description": "CDK Constructs for AWS Lambda in AWS CodePipeline", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fix
@skinny85 I think we should probably recreate this PR. I am currently the author which means that I can't approve the changes. Would you please create a new PR and I'll close this one? |
Will do. |
@eladb what do you think of the name Thoughts on this? |
I think |
Closing--this was moved to #401. |
This continues the refactoring of moving out concrete Action types to modules containing the resource the Action integrates with.
By @skinny85