-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Conversation
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.
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'; |
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.
File names should use hyphens (codebuild-pipeline-action.ts
).
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.
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!! |
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.
If this is still relevant, can you please open an issue with some more context?
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.
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 { |
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.
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.
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.
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'; |
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.
hyphens in file name
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.
Done.
/** | ||
* Source that is provided by an AWS CodeCommit repository | ||
*/ | ||
export class CodeCommitSource extends Source { |
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.
add repository.addToPipeline(stage, name, props)
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.
See above (#265 ).
Thank for the quick review @eladb ! I've submitted a 2nd version with the file names corrected, and an integ test in the |
/** | ||
* Build action that uses AWS CodeBuild | ||
*/ | ||
export class CodeBuildAction extends BuildAction { |
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.
I think this should be renamed to PipelineAction
or CodeBuildPipelineAction
(the word "pipeline" must be there somewhere 😄 )
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.
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
?
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.
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?
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.
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.
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.
I went with PipelineBuildAction
in the new version - it meshes better with codecommit
's PipelineSource
(SourcePipeline
sounds wrong).
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.
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?
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.
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'; |
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.
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.
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.
Changed in all of the integ tests.
} | ||
|
||
/** | ||
* Source that is provided by an AWS CodeCommit repository |
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.
"CodePipeline Source that is provi..."
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.
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.
Ping @eladb - if this looks fine, do you mind merging it in? I don't have permissions. |
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 thecodebuild
project, as that one already depended oncodecommit
, and now, of course, depends oncodepipeline
. 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.