feat(core): allow overriding the stage name

[danilobuerger]

Currently the stage name is derived from the id of the stage and later becomes part of each stack name inside the stage:

aws-cdk/packages/@aws-cdk/core/lib/stage.ts

Line 139 in c425e8c

this.stageName = [this.parentStage?.stageName, id].filter(x => x).join('-');

aws-cdk/packages/@aws-cdk/core/lib/stack.ts

Lines 1139 to 1143 in c425e8c

	private generateStackName() {
	const assembly = Stage.of(this);
	const prefix = (assembly && assembly.stageName) ? `${assembly.stageName}-` : '';
	return `${prefix}${this.generateStackId(assembly)}`;
	}

Since the ids in a scope must be different, deploying the same stage in the same scope to multiple regions would require different ids and would then lead to different stack names in the end. To keep stack names uniform across regions, a stack already allows customising the stack name uncoupled from the id:

aws-cdk/packages/@aws-cdk/core/lib/stack.ts

Lines 106 to 111 in c425e8c

	/**
	* Name to deploy the stack with
	*
	* @default - Derived from construct path.
	*/
	readonly stackName?: string;

This PR follows up on that concept and also allows customising the stage name.

This would then allow to deploy the same stage in the same scope to multiple regions while keeping the resulting stack names the same across regions.

---

All Submissions:

• Have you followed the guidelines in our Contributing guide?

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

[gitpod-io]

[github-actions]

The Pull Request Linter fails with the following errors:

❌ Features must contain a change to a README file.
❌ Features must contain a change to an integration test file and the resulting snapshot.

PRs must pass status checks before we can provide a meaningful review.

[danilobuerger]

The README of core doesn't describe Stage in detail, is it really necessary to modify it for this change?

[TheRealAmazonKendra]

Please make sure that your PR body describes the problem the PR is solving, and the design approach and alternatives considered. Explain why the PR solves the problem. A link to an issue is helpful, but does not replace an explanation of your thought process (See Contributing Guide, Pull Requests)

[danilobuerger]

@TheRealAmazonKendra thanks for helping me. I updated the PR to explain my PR better. I hope its enough?

[aws-cdk-automation]

The Pull Request Linter fails with the following errors:

❌ Features must contain a change to a README file.
❌ Features must contain a change to an integration test file and the resulting snapshot.

PRs must pass status checks before we can provide a meaningful review.

comments addressed

Pull Request updated. Dissmissing previous PRLinter Review.

dismiss

[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: cec7eaf
• 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).