fix(cx-api): bootstrap stack is validated even if the custom synthesizer does not require it

[huyphan]

This fixes #21324

The property requiresBootstrapStackVersion of the class AssetManifestArtifact is a required property of type number that is defaulted to 1. This behavior prevents the custom synthesizers from disabling the validation of the bootstrap stack when it knows that it does not need this stack.

This change allows the property to be undefined, removes the behaviour of defaulting it to 1, and adds a breaking unit test.

---

All Submissions:

• Have you followed the guidelines in our Contributing guide?

Adding new Unconventional Dependencies:

• This PR adds new unconventional dependencies following the process described here

New Features

• Have you added the new feature to an integration test?
  • Did you use yarn integ to deploy the infrastructure and generate the snapshot (i.e. yarn integ without --dry-run)?

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

[gitpod-io]

[mrgrain]

Hey @huyphan Could you share your reasoning why you've chosen Option 1 over Option 2 (as per the issue)?

API elements with incompatible changes:
err  - PROP @aws-cdk/cx-api.AssetManifestArtifact.requiresBootstrapStackVersion: type Optional<number> (formerly number): output type is now optional [changed-type:@aws-cdk/cx-api.AssetManifestArtifact.requiresBootstrapStackVersion]
@aws-cdk/region-info... OK.
Some packages seem to have undergone breaking API changes. Please avoid.

[rix0rrr]

Changing number to number | boolean is just as much of a breaking change as number | undefined is (which ?: number basically comes down to, more or less).

Given that, and since we are the only users of this code anyway, I'm okay with this change. It will break ~ 0 people.

(Watch me regret that stance as this change will bring customers out of the woodwork who this breaks 😅)

The only real alternative is { requiredVersion: number; justKiddingDisregardVersion?: boolean }, which I'd like to avoid if we can. If we end up breaking someone, we can always still move to that.

[huyphan]

Even if there's anyone affected by this breaking change, the impact is negligible -- instead of failing early, the CLI will fail a bit later when it tries to make use of the resources in the bootstrap stack (e.g. uploading assets to the S3 bucket or the ECR repository). But all of that happened before a stack deployment, so it wouldn't affect a service stack.

Also, that scenario only happens when the user (1) uses a custom synthesizer which (2) makes use of the new-style bootstrap stack but (3) does not explicit specify that it needs a new-style bootstrap stack. This is a wrong logic anyway.

[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).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 95bf193
• 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).