feat (pipelines): Follow up on Recent V2 Pipeline Type Implementation

[andreamac003]

Describe the feature

I would like to follow up on #33995 which was recently implemented as part of PR #34005

The upgrade in place for the v2 pipeline type in cdk.pipelines is working great. However, when I try to implement the features in V2 pipeline, I see that some properties are not found, for example, executionMode and triggers are not valid property on pipelines.CodePipeline and so I cannot implement the features available in CodePipeline V2:

    const deploymentPipeline = new pipelines.CodePipeline(this, 'Pipeline', {
      pipelineType: codepipeline.PipelineType.V2,
      executionMode: codepipeline.ExecutionMode.PARALLEL,
      triggers: [{
        providerType: codepipeline.ProviderType.GIT,
        gitConfiguration: {
          push: {
            tags: {
              includes: ['release-*']
            }
          }
        }
      }],
      selfMutation: selfMutation,

The features I am trying to test are found below. In addition to executionMode and triggers, I am not sure what else is needed, but I assume the solution would be to implement the same properties in aws-cdk-lib/aws-codepipeline to now be in the newly updated construct in aws-cdk-lib/pipelines

Use Case

So that we can take advantage of all the CodePipeline v2 features shown above in the newly updated cdk.pipelines CodePipeline construct

Proposed Solution

I believe the solution would be to implement the same properties in aws-cdk-lib/aws-codepipeline to now be in the newly updated construct in aws-cdk-lib/pipelines

Other Information

The documentation I am looking at is below, and so I would like to ensure these features are available for use on the new construct:

Reference: https://docs.aws.amazon.com/codepipeline/latest/userguide/pipeline-types-planning.html

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

2.189.0

Environment details (OS name and version, etc.)

MacOS Sequoia 15.4.1

[ykethan]

Hey @andreamac003, Thank you for reporting this issue. You're correct that while PR #34005 added support for setting pipelineType: codepipeline.PipelineType.V2 in the CDK Pipelines construct, it didn't expose V2-specific properties like executionMode and triggers.

The CodePipelineProps interface in the CDK Pipelines construct would need to be updated to include V2-specific properties:

/**
 * The method that the pipeline will use to handle multiple executions.
 * 
 * `executionMode` can only be used when `pipelineType` is set to `PipelineType.V2`.
 *
 * @default - ExecutionMode.SUPERSEDED
 */
readonly executionMode?: cp.ExecutionMode;

/**
 * The trigger configuration specifying a type of event, such as Git tags, that
 * starts the pipeline.
 *
 * When a trigger configuration is specified, default change detection for repository
 * and branch commits is disabled.
 *
 * `triggers` can only be used when `pipelineType` is set to `PipelineType.V2`.
 *
 * @default - No triggers
 */
readonly triggers?: cp.TriggerProps[];

/**
 * A list that defines the pipeline variables for a pipeline resource.
 *
 * `variables` can only be used when `pipelineType` is set to `PipelineType.V2`.
 *
 * @default - No variables
 */
readonly variables?: cp.Variable[];

Until this is implemented, I did notice the following workaround where i was able to access V2 features:
Did noticed we can pass a existing codepipeline reference to the CDK pipeline with additional configuration

import * as codepipeline from 'aws-cdk-lib/aws-codepipeline';
import * as pipelines from 'aws-cdk-lib/pipelines';

// Create the underlying CodePipeline directly with V2 features
const underlyingPipeline = new codepipeline.Pipeline(this, 'Pipeline', {
  pipelineType: codepipeline.PipelineType.V2,
  executionMode: codepipeline.ExecutionMode.PARALLEL,
  // Other V2-specific properties as needed
  restartExecutionOnUpdate: true,
});

// Use this pre-configured pipeline in CDK Pipelines
const cdkPipeline = new pipelines.CodePipeline(this, 'CdkPipeline', {
  // Pass the pre-configured pipeline with V2 features
  codePipeline: underlyingPipeline,
  selfMutation: true,
  synth: new pipelines.ShellStep('Synth', {
    // Your synth configuration
  }),
});

[andreamac003]

Hi @ykethan , thank you for the quick reply!

Yes, so our team has tried that same workaround provided in the cdk community slack channel, but unfortunately our team ran into some errors with that approach, which is what prompted us to raise the original feature request for support on the pipelines.CodePipeline construct. If your team is able to apply these features to this construct directly, we would greatly appreciate it 🙌

[ykethan]

@andreamac003 interesting, would you be able to share some insights on the issues you experienced. If you do believe they may be bugs do create a issue we would be happy in diving into them.

[andreamac003]

Thanks @ykethan , I'll have to go back and see what the specific errors were, but I do know one of the big issues for us with that workaround is that it created a new pipeline rather than updating the existing one in place, so we needed a solution where we could keep the same pipeline

[hwum]

Hi Community,
Thanks for raising this request. cdk-pipelines (L3)library is dedicated to specific use cases for codepipeline, it would not support single functionality like the aws-codepipeline (L2)does. It would be great if you could bring up a common use case including these V2 features of full pipeline and we could consider to add it into L3 construct.
Currently, the workaround would be use fromPipelineArn(https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-codepipeline/lib/pipeline.ts#L538)function to import your pipeline created by L3 construct into L2 construct and you could add the feature you listed above into your pipeline.
Appreciate it again for raising the request for us to build better library together.
Codepipeline dev