(pipelines): v1 Cloud Assembly Schema version bumps break pipelines until v2 CDK CLI is released #18370
Comments
misterjoshua
added
bug
misterjoshua
changed the title
|
@rix0rrr and CDK team friends - it would be helpful to make it clear if CDK CLI v2 is supposed to work with CDK v1 Apps. When I read the "CDK Toolkit compatibility" section of the migration doc, I thought CDK CLI v2 could work with either v1 or v2 CDK apps (I could be totally wrong 😄). Thanks for your help on this! 🍻 |
ryparker
added
p2
and removed
needs-triage
|
Yes, CLIv2 works with v1 apps. It's just that the way our release train works, the statement "the CLI must have equal version or higher" becomes a bit inscrutable. This situation is an artifact of us still supporting (and developing on) v1 for the next 6 months. Once we drop support for v1, all future changes will go into v2 directly and any inconsistency windows will disappear.
|
We are currently releasing both v1 and v2 streams of the CDK in parallel, with changes landing on v1 before they land on v2. By default, CDK Pipelines will use the "latest" CLI version. However, because "latest" always comes from the v2 version stream (since that has the highest number), there may be changes to the cx protocol in a v1 app that aren't supported by the v2 CLI yet. The "correct" solution to this would be one of (a) releasing v1 and v2 synchronously and making sure both have the same change set; or (b) not having a v2 CLI at all. Both of these would require significant engineering effort to resolve though. In the mean time, add the concept of a "preferred CLI version" to CDK Pipelines, set to `1` for most packages but to `2` for `aws-cdk-lib`, and have NPM install the "latest" CLI from the same version stream that the library is from. Fixes #18370.
We are currently releasing both v1 and v2 streams of the CDK in parallel, with changes landing on v1 before they land on v2. By default, CDK Pipelines will use the "latest" CLI version. However, because "latest" always comes from the v2 version stream (since that has the highest number), there may be changes to the cx protocol in a v1 app that aren't supported by the v2 CLI yet. The "correct" solution to this would be one of (a) releasing v1 and v2 synchronously and making sure both have the same change set; or (b) not having a v2 CLI at all. Both of these would require significant engineering effort to resolve though. In the mean time, add the concept of a "preferred CLI version" to CDK Pipelines, set to `1` for most packages but to `2` for `aws-cdk-lib`, and have NPM install the "latest" CLI from the same version stream that the library is from. Fixes #18370. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
We are currently releasing both v1 and v2 streams of the CDK in parallel, with changes landing on v1 before they land on v2. By default, CDK Pipelines will use the "latest" CLI version. However, because "latest" always comes from the v2 version stream (since that has the highest number), there may be changes to the cx protocol in a v1 app that aren't supported by the v2 CLI yet. The "correct" solution to this would be one of (a) releasing v1 and v2 synchronously and making sure both have the same change set; or (b) not having a v2 CLI at all. Both of these would require significant engineering effort to resolve though. In the mean time, add the concept of a "preferred CLI version" to CDK Pipelines, set to `1` for most packages but to `2` for `aws-cdk-lib`, and have NPM install the "latest" CLI from the same version stream that the library is from. Fixes aws#18370. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
What is the problem?
v1.139.0 synthesizes Cloud Assembly Schema Version 16.0.0, but the latest CLI doesn't support it. In CDK Pipelines, without explicitly setting
cliVersion: '1', the self-mutation step currently fails.I'm sure that v2's CLI will be released soon, but given that the latest CLI may continue to be released out of step with (and later than) v1 schema version bumps, I wonder if many Pipelines users will get caught by this issue whenever v1 gets the schema bump first, like until the user sets cliVersion explicitly.
Reproduction Steps
https://cdk-dev.slack.com/archives/C018XT6REKT/p1641967038204400?thread_ts=1641940855.193800&cid=C018XT6REKT
What did you expect to happen?
Pipelines should use CDK CLI v1 to self-mutate.
What actually happened?
Pipelines used CDK CLI v2 (latest) which doesn't yet support the latest Cloud Assembly Schema Version, so it threw an error.
CDK CLI Version
2.5.0
Framework Version
1.139.0
Node.js Version
N/A
OS
Linux
Language
Typescript
Language Version
TypeScript (4.5.4)
Other information
Would it make the user's life easier if the Pipelines construct defaulted cliVersion to "1" rather than blank when synthesizing a v1 app? The changes would be here:
aws-cdk/packages/@aws-cdk/pipelines/lib/codepipeline/codepipeline.ts
Line 606 in e23b63f
aws-cdk/packages/@aws-cdk/pipelines/lib/codepipeline/codepipeline.ts
Line 652 in e23b63f
The text was updated successfully, but these errors were encountered: