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

Moved the LambdaInvoke Action from the codepipeline module to the Lambda module #348

Closed
wants to merge 1 commit into from
Closed

Moved the LambdaInvoke Action from the codepipeline module to the Lambda module #348

wants to merge 1 commit into from

Conversation

eladb
Copy link
Contributor

@eladb eladb commented Jul 16, 2018

This continues the refactoring of moving out concrete Action types to modules containing the resource the Action integrates with.

By @skinny85

@eladb eladb changed the title Feature/lambda action move Moved the LambdaInvoke Action from the codepipeline module to the Lambda module Jul 16, 2018
@skinny85
Copy link
Contributor

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';
Copy link
Contributor

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.

Copy link
Contributor

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 :)

Copy link
Contributor Author

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 🎂

@eladb
Copy link
Contributor Author

eladb commented Jul 17, 2018

@skinny85 the build break is caused by a dependency cycle: lambda => codecommit => sns => lambda.

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 find-cycle:

Cycle: @aws-cdk/iam => @aws-cdk/assert => aws-cdk => @aws-cdk/s3 => @aws-cdk/kms => @aws-cdk/iam
Cycle: @aws-cdk/assert => aws-cdk => @aws-cdk/s3 => @aws-cdk/kms => @aws-cdk/assert
Cycle: @aws-cdk/iam => @aws-cdk/assert => aws-cdk => @aws-cdk/s3 => @aws-cdk/iam
Cycle: @aws-cdk/assert => aws-cdk => @aws-cdk/s3 => @aws-cdk/assert
Cycle: @aws-cdk/assert => aws-cdk => @aws-cdk/cloudformation => @aws-cdk/assert
Cycle: @aws-cdk/iam => @aws-cdk/assert => aws-cdk => @aws-cdk/util => @aws-cdk/iam
Cycle: @aws-cdk/sns => @aws-cdk/lambda => @aws-cdk/codecommit => @aws-cdk/sns
Cycle: @aws-cdk/sns => @aws-cdk/lambda => @aws-cdk/codecommit => @aws-cdk/codepipeline => @aws-cdk/sns

P.S. the other cycles are related to #32

@skinny85
Copy link
Contributor

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 codecommit.

… to its dedicated, new lambda-codepipeline module.

This continues the refactoring of moving out concrete Action types
from the codepipeline module.
@skinny85
Copy link
Contributor

Completely changed the approach.

The dependencies right now look like this:

codepipeline -> sns -> lambda

So, lambda cannot depend on codepipeline, as that would be a cycle.

Because of that, I've extracted a separate lambda-codepipeline module. I think breaking out all of the integrations with codepipeline into their own submodules make a lot of sense - in that way, all of the modules in @aws-cdk are smaller, and have less dependencies. Also, it lets us break out the S3 Action out of the codepipeline module (codepipeline already depends on s3 for Bucket management).

Let me know if there are any objections to this approach.

@@ -1,4 +1,7 @@
import { Stack } from '@aws-cdk/core';
Copy link
Contributor Author

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
Copy link
Contributor Author

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';
Copy link
Contributor Author

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';
Copy link
Contributor Author

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",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

fix

@eladb
Copy link
Contributor Author

eladb commented Jul 24, 2018

@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?

@skinny85
Copy link
Contributor

@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.

@skinny85
Copy link
Contributor

@eladb what do you think of the name lambda-codepipeline? In a meeting today @RomainMuller suggested that perhaps codepipeline-lambda would be a better name (it would make these integration modules a little easier to discover).

Thoughts on this?

@eladb
Copy link
Contributor Author

eladb commented Jul 24, 2018

I think lambda-pipeline makes more sense because eventually it's a "feature" of Lambda and not pipeline

@skinny85
Copy link
Contributor

Moved to #401 , feel free to close this one @eladb

@skinny85 skinny85 deleted the feature/lambda-action-move branch July 30, 2018 18:24
@mpiroc
Copy link
Contributor

mpiroc commented Jul 31, 2018

Closing--this was moved to #401.

@mpiroc mpiroc closed this Jul 31, 2018
@NGL321 NGL321 added the contribution/core This is a PR that came from AWS. label Sep 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contribution/core This is a PR that came from AWS.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants