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

Move the CodeCommit and CodeBuild Actions from the codepipeline module into their @aws-cdk modules #238

Merged
merged 1 commit into from
Jul 16, 2018
Merged

Move the CodeCommit and CodeBuild Actions from the codepipeline module into their @aws-cdk modules #238

merged 1 commit into from
Jul 16, 2018

Conversation

skinny85
Copy link
Contributor

@skinny85 skinny85 commented Jul 6, 2018

As agreed to with the CodePipeline team,
we want to move the concrete Action types from the codepipeline module
and into the modules of the resources they represent integrations with.
This is doing this refactoring for CodeCommit Repositories and CodeBuild Projects.

The most interesting part of this PR is where to put the tests that were in the codepipeline module. They can't be there anymore, as they relied on creating CodeCommit and CodeBuild Actions, and so that would result in a circular dependency. I moved them to the codebuild project, as that one already depended on codecommit, and now, of course, depends on codepipeline. But, I'm open to suggestions on a different approach (separate module for the tests maybe?).


By submitting this pull request, I confirm that my contribution is made under
the terms of the beta license.

Copy link
Contributor

@eladb eladb left a comment

Choose a reason for hiding this comment

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

Looks good. See some feedback about adding addToPipeline methods to ease discoverability and improve the ergonomics of using these resources within a pipeline. I am okay if you prefer to open an issue and implement this as a 2nd phase.

Regarding testing: I think the codepipeline library should test the "framework", and each integration (i.e. code-commit, code-build, etc) should have tests that verify the integration. In that regard, I would add another integration test to code-commit that verifies just the code-commit source behavior.

@@ -0,0 +1,59 @@
import { Artifact, BuildAction, 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.

File names should use hyphens (codebuild-pipeline-action.ts).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

// allow codebuild to read and write artifacts to the pipline's artifact bucket.
parent.pipeline.artifactBucket.grantReadWrite(props.project.role);

// policy must be added as a dependency to the pipeline!!
Copy link
Contributor

Choose a reason for hiding this comment

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

If this is still relevant, can you please open an issue with some more context?

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'm actually not sure. This comment has been here before (I've only moved it). The Pipeline already depends on both the Pipeline Role and on the Policy Document that Role uses. Perhaps this comment is no longer relevant?

/**
* Build action that uses AWS CodeBuild
*/
export class CodeBuildAction extends BuildAction {
Copy link
Contributor

Choose a reason for hiding this comment

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

Since this is already in the codebuild library, wouldn't it make sense to make this discoverable directly from the project? I am envisioning something like buildProject.addToPipeline(stage, name, props). This could be a nice pattern to allow easy discovery of AWS resources that can be used as pipeline actions.

P.S. When we implement #181 we could use this pattern to identify pipeline actions and provide rich IDE and tools support for pipeline definitions.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good, but, like you said, I'd rather do this change separately (this one is only about moving files around). I've filed #265 to not lose track of this.

@@ -1 +1,2 @@
export * from './codecommit';
export * from './codecommit_pipeline_action';
Copy link
Contributor

Choose a reason for hiding this comment

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

hyphens in file name

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

/**
* Source that is provided by an AWS CodeCommit repository
*/
export class CodeCommitSource extends Source {
Copy link
Contributor

Choose a reason for hiding this comment

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

add repository.addToPipeline(stage, name, props)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See above (#265 ).

@skinny85 skinny85 changed the title Move the CodeCommit and CodeBuild Actions from the codepipeline modules into their @aw-cdk modules Move the CodeCommit and CodeBuild Actions from the codepipeline module into their @aws-cdk modules Jul 9, 2018
@skinny85
Copy link
Contributor Author

skinny85 commented Jul 9, 2018

Thank for the quick review @eladb ! I've submitted a 2nd version with the file names corrected, and an integ test in the codecommit module for its interactions with CodePipeline.

/**
* Build action that uses AWS CodeBuild
*/
export class CodeBuildAction extends BuildAction {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this should be renamed to PipelineAction or CodeBuildPipelineAction (the word "pipeline" must be there somewhere 😄 )

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There's actually quite a (stupid?) subtlety here. There are actually 2 CodeBuild Actions in the codepipeline module (the other is simply commented out right now). The difference between them is the category they use. The first one (this one) has category ActionCategory.Build, while the other one has ActionCategory.Test (it's used for approval steps). They are also constructed a little bit differently (the one with ActionCategory.Test doesn't produce any output artifacts, for example).

Given that, does it make sense to name this CodeBuildPipelineAction, and then the other class CodeBuildTestPipelineAction?

Copy link
Contributor

Choose a reason for hiding this comment

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

How about BuildPipelineAction and TestPipelineAction. We are in the CodeBuild module, so everything is namespaced by codebuild anyway.

P.S. how will this work with addToPipeline() will we need two addToPipeline or will it take a property indicating if this is a build or test action?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

How about BuildPipelineAction and TestPipelineAction. We are in the CodeBuild module, so everything is namespaced by codebuild anyway.

That would be a departure from how we named those previously. In theory, a customer can import * from @aws-cdk/codebuild, right? In which case there would no context, as the L2s are in the default namespace.

However, if we're changing this convention, I'm fine with that.

P.S. how will this work with addToPipeline() will we need two addToPipeline or will it take a property indicating if this is a build or test action?

Not sure. My first instinct is having 2 addToPipeline()s, but I guess we can discuss it in more depth when we add those methods.

Copy link
Contributor Author

@skinny85 skinny85 Jul 11, 2018

Choose a reason for hiding this comment

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

I went with PipelineBuildAction in the new version - it meshes better with codecommit's PipelineSource (SourcePipeline sounds wrong).

Copy link
Contributor

Choose a reason for hiding this comment

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

Can you make sure to add a note to #265 that emphasizes the fact that a CodeCommit project can serve two different roles in a pipeline?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can you make sure to add a note to #265 that emphasizes the fact that a CodeCommit project can serve two different roles in a pipeline?

Done.

@@ -1,17 +1,18 @@
import { BuildProject, CodePipelineSource } from '@aws-cdk/codebuild';
import { Repository } from '@aws-cdk/codecommit';
import { PipelineSource, Repository } from '@aws-cdk/codecommit';
Copy link
Contributor

Choose a reason for hiding this comment

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

We decided to move to "*" imports, which will make this code more readable, so import * as codecommit from '@aws-cdk/codecommit' and then codecommit.PipelineSource will make much more sense.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed in all of the integ tests.

}

/**
* Source that is provided by an AWS CodeCommit repository
Copy link
Contributor

Choose a reason for hiding this comment

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

"CodePipeline Source that is provi..."

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

…eline module into their @aws-cdk modules.

As agreed to with the CodePipeline team,
we want to move the concrete Action types from the codepipeline module
and into the modules of the resources they represent integrations with.
This is doing this refactoring for CodeCommit Repositories and CodeBuild Projects.
@skinny85
Copy link
Contributor Author

Ping @eladb - if this looks fine, do you mind merging it in? I don't have permissions.

@eladb eladb merged commit 248c503 into aws:master Jul 16, 2018
@skinny85 skinny85 deleted the feature/code-actions-move-backup branch July 16, 2018 19:23
@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.

3 participants