Add an addToPipeline method for L2 Constructs like CodeCommit Repositories and CodeBuild Projects

[skinny85]

As discussed in the comments of #238 .

[skinny85]

It's important to note that there are two different CodeBuild Actions in a CodePipeline - one has category equal to Build, the other - Test. We need to take this into consideration when implementing this feature.

[skinny85]

@eladb I'm not sure if we can do this anymore :(. With the recent trend of moving out Actions into their own modules, the L2s libraries like CodeCommit / CodeBuild / Lambda no longer depend on the codepipeline module (and indeed can't depend on it in some cases, like lambda and s3, without running into cyclic dependencies).

Without that dependency, there's no way to construct a method like:

codecommit.Repository.addToPipeline(
    stage: codepipeline.Stage,
    id: string,
    props: codecommit.PipelineSourceProps)

[eladb]

Yes, I figured. That's a little sad. Perhaps at least lets add a reference to the pipeline support in the README of the various modules (and in the README for codepipelines)

[skinny85]

Now that #459 has been pushed, we can do this again!

I'm wondering what should the API look like? Here's my first draft, based on CodeCommit Repository:

const pipeline = new codepipeline.Pipeline(this, 'MyPipeline');
const sourceStage = new codepipeline.Stage(this, 'Source', { pipeline });
const repository = new codecommit.Repository(this, 'MyRepo', {
    repositoryName: 'MyRepo',
});

const sourceAction = repository.useAsSourceInPipeline(sourceStage, {
    artifactName: 'SourceOutput',
    runOrder: 99,
    // other Action-level properties here...
});

// use sourceAction.artifact here as input to subsequent Actions...

Does this make sense?

[eladb]

Here are some ideas @skinny85 and I have been talking about:

const repository = new codecommit.Repository(this, 'MyRepo', {
    repositoryName: 'MyRepo',
});

const pipeline = new codepipeline.Pipeline(this, 'MyPipeline');

const stage = pipeline.addStage('Source');
stage.addSourceAction(repository, { actionName: 'MySource', runOrder: 99 });
stage.addBuildAction(

class Repository implements IPipelineSource {
    /** use stage.addSourceAction(repo) **/
    public asPipelineSource(pipeline: Pipeline, name?: string) {
        new RepositoryCodePipelineSourceAction(this, 'Source', { pipeline });
    }
}

[RomainMuller]

So the stage.addSourceAction is going to be awkward if it needs to pass props down to the IPipelineSource#asPipelineSource, since those will not always the the same type. Making it type-safe would involve using a convoluted generic declaration, which jsii wouldn't be able to process currently.

A first step would be to reverse the direction and have:

// In @aws-cdk/aws-s3
export class Bucket /*...*/ {
    /*...*/
    public addToPipelineStage(stage: codepipeline.Stage, id: string, props: { path: string }) {
        new S3CodePipelineSourceAction(this, id, { ...props, stage });
    }
}

This solves the problem of the props type being heterogenous, and makes discoverability of pipeline actions from the providers more straight-forward. Also helps hiding the long class names for the PipelineAction classes.

If/when jsii supports generics, we can make the action providers implement (obviously can also have specialized IPipelineSourceActionProvider<Props> and whatnot):

export interface IPipelineActionProvider<Props> {
    addToPipelineStage(stage: codepipeline.Stage, name: string, props: Props): codepipeline.Action;
}

And then provide a Stage method such as, in order to allow development workflows that start with the pipeline and work from there:

export class Stage /*...*/ {
    /*...*/
    public addSourceAction<Props>(provider: IPipelineActionProvider<Props>, name: string, props: Props) {
        return provider.addToPipelineStage(this, name, props);
    }
}

[skinny85]

First (of probably many) PR: #616

[skinny85]

Second PR: #642

[skinny85]

Third PR: #647

[skinny85]

I'm resolving this one, as all 3 PRs have been merged.