fix(pipelines): generates warning since CDK 2.128.0 due to addition of v2 pipeline support in aws-codepipeline

[gossandr]

Issue # (if applicable)

Closes #29190

Reason for this change

CDK v2.128.0 introduced a warning in aws-codepipeline to warn users of the implicit behavior now that v2 pipelines are supported in CDK. This warning can cause established pipelines to fail if they are using cdk synth --strict. The warning can be suppressed, but the better fix is to have this module supply the PipelineType added in CDK v128.0 and set it to v1. A future change would have to address adding v2 pipeline support to this module, this only resolves the introduced warning.

Description of changes

• added the optional (and new) PipelineType property in the creation of the codepipeline in https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/pipelines/lib/codepipeline/codepipeline.ts#L467-L480
• slightly modified the README where it mentions using aws-codepipeline to include specifically an mention of v2 as a reason to use aws-codepipeline (until of course v2 is added properly in this lib)

Description of how you validated changes

• reverted a change in 40ffe2b as I believe this previously caught the new warning and was changed to fix the test rather than looking into the new warning. This would catch the warning if PipelineType is not supplied

Checklist

• [ x] My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

[gossandr]

Exemption Request
I don't think updated integration tests are necessary here. The modification in the props that are supplied to creating the new CodePipeline (from the aws-codepipeline lib) will not produce a change in output. Current behavior was to assume v1 and add warning annotation, now with the property set on creation no warning is generated. Otherwise exactly the same pipeline is created.

[gossandr]

Exemption Request I don't think updated integration tests are necessary here. The modification in the props that are supplied to creating the new CodePipeline (from the aws-codepipeline lib) will not produce a change in output. Current behavior was to assume v1 and add warning annotation, now with the property set on creation no warning is generated. Otherwise exactly the same pipeline is created.

So i think I was wrong and they are required...but i could use some guidance perhaps 😅

[gossandr]

So I did try to run the integration tests and i got to a point where some of them fail with InternalFailure as mentioned in this PR #28447

Here are the tests that failed:

packages/@aws-cdk-testing/framework-integ/test/pipelines/test/integ.newpipeline-with-codebuild-logging.js
packages/@aws-cdk-testing/framework-integ/test/pipelines/test/integ.newpipeline-with-cross-account-keys.js
packages/@aws-cdk-testing/framework-integ/test/pipelines/test/integ.newpipeline-with-cross-region-replication-buckets.js
packages/@aws-cdk-testing/framework-integ/test/pipelines/test/integ.newpipeline-with-vpc.js
packages/@aws-cdk-testing/framework-integ/test/pipelines/test/integ.newpipeline.js

From what i read in the conversation on the PR I linked, my impression here is that if I want to get these to pass in the short term I will need to do the following:

• fork the cdk-pipelines-demo referenced in the tests to my personal github
• update all these tests to point to the forked repo
• fix any other problems in the test related to them being semi-bound to the user who runs them
• re-run the integration tests with the update on failed flag.

before i go down this road I wanted to maybe get a confirmation that I'm on the right track 😅

[kaizencc]

Yes @gossandr that would be the correct way to update those tests. it may be quite time-intensive. I see that the snapshot diff is simply explicitly specifying pipeline v1. That is to be expected, and in this case I am happy to assume that CFN accepts the property happily since it is exactly as documented.

In this case, I am happy with you doing a shortcut:

run the integration tests with --update-on-failed --dry-run. This will simply update the snapshots without deploying the integ test. Not great, but I don't think this is a high risk change to the snapshot.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

Pull request has been modified.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 0ef17a5
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).