Skip to content

feat(toolkit-lib)!: parameterize context storage #534

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 10 commits into from
May 27, 2025
Merged

Conversation

rix0rrr
Copy link
Contributor

@rix0rrr rix0rrr commented May 26, 2025

Previously, context was always being written to cdk.context.json in some directory, even for fromAssemblyBuilder() or fromAssemblyDirectory() which should probably both not write context anywhere.

In this PR, we replace the context parameter to the toolkit with the concept of a contextStore, which has two operations: read() and update().

There are simple file and in-memory implementations for simple cases, as well as the more complex CDK app case which is implemented as CdkAppMultiContext. That last one is the default for fromCdkApp().

The complex one is implemented in terms of the prior Context/ContextBag/Settings classes, which are probably overly complex for the job this class is doing but keeping the old classes is an easy way to make sure that the behavior stays compatible.

BREAKING CHANGES: context is now called contextStore. Message CDK_ASSEMBLY_I0042 no longer knows about the filename where changes get written.


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

Previously, context was always being written to `cdk.context.json` in
some directory, even for `fromAssemblyBuilder()` or
`fromAssemblyDirectory()` which should probably both not write context
anywhere.

In this PR, we replace the context parameter to the toolkit with the
concept of a `contextStore`, which has two operations: `read()` and
`update()`.

There are simple file and in-memory implementations for simple cases, as
well as the more complex CDK app case which is implemented as
`CdkAppMultiContext`. That last one is the default for `fromCdkApp()`.

The complex one is implemented in terms of the prior
`Context/ContextBag/Settings` classes, which are probably overly
complex for the job this class is doing but keeping the old classes
is an easy way to make sure that the behavior stays compatible.
@aws-cdk-automation aws-cdk-automation requested a review from a team May 26, 2025 12:48
@rix0rrr rix0rrr disabled auto-merge May 26, 2025 12:48
@rix0rrr
Copy link
Contributor Author

rix0rrr commented May 26, 2025

TODO: Write tests for the new classes, verify that none of them persist transient errors.

@rix0rrr rix0rrr self-assigned this May 26, 2025
private projectContextFile: string;
private userConfigFile: string;

constructor(appDirectory: string, private readonly initialContext?: Record<string, unknown>) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only FileContext does not get initialContext?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. The name is probably bad here.

@codecov-commenter
Copy link

codecov-commenter commented May 26, 2025

Codecov Report

Attention: Patch coverage is 0% with 5 lines in your changes missing coverage. Please review.

Project coverage is 79.09%. Comparing base (70128c0) to head (2bc768b).
Report is 2 commits behind head on main.

Files with missing lines Patch % Lines
packages/aws-cdk/lib/cxapp/cloud-executable.ts 0.00% 5 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #534      +/-   ##
==========================================
+ Coverage   79.01%   79.09%   +0.08%     
==========================================
  Files          47       47              
  Lines        7032     7035       +3     
  Branches      786      786              
==========================================
+ Hits         5556     5564       +8     
+ Misses       1458     1453       -5     
  Partials       18       18              
Flag Coverage Δ
suite.unit 79.09% <0.00%> (+0.08%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@@ -125,7 +131,7 @@ export abstract class CloudAssemblySourceBuilder {
const services: ToolkitServices = await this.sourceBuilderServices();
const contextAssemblyProps: ContextAwareCloudAssemblyProps = {
services,
context: new Context(), // @todo there is probably a difference between contextaware and contextlookup sources
contextStore: new MemoryContext(), // FIXME: We shouldn't be using a `ContextAwareCloudAssemblySource` at all.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lol. are we fighting over what the best todo/fixme marker is?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, sorry. Not on purpose. Deleted this line without looking, then rewrote it 🤣

@rix0rrr rix0rrr added this pull request to the merge queue May 27, 2025
Merged via the queue into main with commit 95971c0 May 27, 2025
21 checks passed
@rix0rrr rix0rrr deleted the huijbers/context-store branch May 27, 2025 14:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants