feat(core): support adding additional cache key to cdk context values #26984

luxaritas · 2023-09-02T03:46:06Z

The ContextProvider mechanism and various "lookup" functions of a number of constructs support caching resolved values in the cdk.context.json. The context keys are constructed from the parameters of the lookup, which for lookup functions means whenever a resource with the same parameters is resolved, it is resolved as the same value across the entire app. However when a value may change over time, the user may wish to use the latest value when creating creating a new reference to the construct, effectively tying the cached context value to the scope - this patch enables this.

The primary use case is looking up an AMI parameter for a "stateful" EC2 instance. Currently if you specify cachedInContext, any future images created would use the same cached AMI, and updating the value would require updating all usages of the image across the entire app.

Closes #26982

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.

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

luxaritas · 2023-09-02T05:41:21Z

Some open questions/areas I am particularly looking for feedback on (especially being less familiar with standards as a new contributor):

I added a new optional parameter wherever I extended a lookup function. This was the simplest and most consistent backward-compatible option, however I don't find it a particularly elegant API (whereas most other areas of the API are really good about throwing miscellaneous options in options objects for extensibility). What's the preferred approach here?
I added the option to all lookups that called ContextProvider.getValue, aside from AZ lookups where I felt it particularly didn't make sense. Was this the correct call? Would it be better to limit this just to AMIs and parameters which are more likely to have a concrete use case for this (where different values across time are useful concurrently)?
I added tests where there were already context-related tests that I could find, as well as an integration test for a machine image lookup which is the most complex out of the largely-identical situations created here. Should I add tests elsewhere?

luxaritas · 2023-09-02T06:07:02Z

One more potential question: should linkContextToScope optionally take a Construct instead of a boolean so that it could be linked to a specific scope as opposed to the scope the value is directly used in? Though given the inability of unions to be used per the design guidelines, I'm not sure what the ideal way to model that would be...

…etImage

rix0rrr

Hey, thanks for the idea and the contribution!

I have to say that I'm reflexively experiencing an aversion to this proposed change 🤢😝 because why would those values ever be different? But I can also appreciate that this is necessary to evolve a stateful app over time.

The solution of including the scope is clever... but I wonder if it doesn't give more flexibility at the cost of a vague contract.

Could we do something blindingly obvious instead, have the user include a cache busting key? And then everyone can reuse/invalidate that key on a per-location basis as they desire?

ec2.MachineImage.latestAmazonLinux2023({
  cachedInContext: true,

  additionalCacheKey: 'asdf',  // Can change this to qwerty whenever I feel like updating it
});

They can still make that be the scope if they want to (achieving the current behavior) by passing this.node.path.

luxaritas · 2023-09-19T13:06:29Z

Hey @rix0rrr! I do think that makes sense, and now that you say that I realize that did feel a bit weird. I imagine that cache key would be used as the value of a prop passed to the context, I'm thinking maybe call they key of that prop userCacheKey. I'll adjust the PR shortly and we can continue discussion from there

Pull request has been modified.

luxaritas · 2023-09-19T20:00:58Z

I also wound up moving additionalCacheKey into the lookup props - it seems like it wound up being cleaner. I'll adjust the PR title and description to match the change

lpizzinidev

Thanks (and sorry for the late review) 👍
I left you some comments as a first revision.

lpizzinidev · 2023-10-30T14:10:40Z

packages/@aws-cdk-testing/framework-integ/test/aws-ec2/test/integ.machine-image-cached.ts

+  aws_ec2 as ec2,
+  // aws_autoscaling as asg,
+  // aws_ssm as ssm,
+} from 'aws-cdk-lib';


Suggested change

aws_ec2 as ec2,

// aws_autoscaling as asg,

// aws_ssm as ssm,

} from 'aws-cdk-lib';

} from 'aws-cdk-lib';

import * as ec2 from 'aws-cdk-lib/aws-ec2';

lpizzinidev · 2023-10-30T14:13:25Z

packages/@aws-cdk-testing/framework-integ/test/aws-ec2/test/integ.machine-image-cached.ts

+const app = new App();
+new IntegTest(app, 'integ-test', {
+  testCases: [new TestCase(app, 'integ-ec2-machine-image-cached-test', { env })],
+  enableLookups: true,
+});


Suggested change

const app = new App();

new IntegTest(app, 'integ-test', {

testCases: [new TestCase(app, 'integ-ec2-machine-image-cached-test', { env })],

enableLookups: true,

});

const app = new App();

const stack = new TestCase(app, 'cdk-ec2-machine-image-cached', { env });

new IntegTest(app, 'integ-ec2-machine-image-cached', {

testCases: [stack],

enableLookups: true,

});

app.synth();

lpizzinidev · 2023-10-30T14:17:47Z

packages/aws-cdk-lib/aws-ec2/lib/machine-image/machine-image.ts

  constructor(private readonly props: AmazonLinuxImageProps = {}) {
    super(AmazonLinuxImage.ssmParameterName(props), OperatingSystemType.LINUX, props.userData);

    this.cachedInContext = props.cachedInContext ?? false;
+    if (props.additionalCacheKey) this.additionalCacheKey = props.additionalCacheKey;


Suggested change

if (props.additionalCacheKey) this.additionalCacheKey = props.additionalCacheKey;

this.additionalCacheKey = props.additionalCacheKey;

lpizzinidev · 2023-10-30T14:18:42Z

packages/aws-cdk-lib/aws-ecs/lib/amis.ts

@@ -145,13 +152,14 @@ export class EcsOptimizedAmi implements ec2.IMachineImage {
      + (this.windowsVersion ? 'image_id' : 'recommended/image_id');

    this.cachedInContext = props?.cachedInContext ?? false;
+    if (props?.additionalCacheKey) this.additionalCacheKey = props.additionalCacheKey;


Suggested change

if (props?.additionalCacheKey) this.additionalCacheKey = props.additionalCacheKey;

this.additionalCacheKey = props?.additionalCacheKey;

lpizzinidev · 2023-10-30T14:19:24Z

packages/aws-cdk-lib/aws-ecs/lib/amis.ts

@@ -385,8 +410,8 @@ Object.defineProperty(BottleRocketImage.prototype, BR_IMAGE_SYMBOL, {
  writable: false,
 });

-function lookupImage(scope: Construct, cachedInContext: boolean | undefined, parameterName: string) {
+function lookupImage(scope: Construct, cachedInContext: boolean, parameterName: string, additionalCacheKey?: string) {


Suggested change

function lookupImage(scope: Construct, cachedInContext: boolean, parameterName: string, additionalCacheKey?: string) {

function lookupImage(scope: Construct, cachedInContext?: boolean, parameterName: string, additionalCacheKey?: string) {

Why change cachedInContext's type?

I think this was a result of an intermediate change. (Also has to be | undefined since later properties cant be required if an earlier one is not, but that's no matter)

Out of curiosity: This appears to be an "internal" function that is never called with undefined - does this still have a backward-compat issue just by virtue of it being exported?

lpizzinidev · 2023-10-30T14:41:05Z

packages/aws-cdk-lib/aws-ec2/lib/vpc.ts

@@ -1292,6 +1292,7 @@ export class Vpc extends VpcBase {
        returnAsymmetricSubnets: true,
        returnVpnGateways: options.returnVpnGateways,
        subnetGroupNameTag: options.subnetGroupNameTag,
+        ...(options.additionalCacheKey ? { additionalCacheKey: options.additionalCacheKey } : {}),


Suggested change

...(options.additionalCacheKey ? { additionalCacheKey: options.additionalCacheKey } : {}),

additionalCacheKey: options.additionalCacheKey,

The parameter should be added in the corresponding interface (same for other getValue calls).

Just noticed that undefined values are stripped in context-provider. props is just { [key: string]: any }, so I think there's nothing to do beyond that?

...never mind, I see the interface this is being specified as.

lpizzinidev · 2023-10-30T14:41:35Z

packages/aws-cdk-lib/aws-ecs/lib/amis.ts

@@ -258,14 +273,15 @@ export class EcsOptimizedImage implements ec2.IMachineImage {
      + (this.hwType === AmiHardwareType.ARM ? 'arm64/' : '')
      + (this.windowsVersion ? 'image_id' : 'recommended/image_id');

-    this.cachedInContext = props?.cachedInContext ?? false;
+    this.cachedInContext = props.cachedInContext ?? false;
+    if (props.additionalCacheKey) this.additionalCacheKey = props.additionalCacheKey;


Suggested change

if (props.additionalCacheKey) this.additionalCacheKey = props.additionalCacheKey;

this.additionalCacheKey = props.additionalCacheKey;

lpizzinidev · 2023-10-30T14:48:02Z

packages/aws-cdk-lib/aws-ec2/README.md

+If you do not want the value of the context variable to be global (ie, having the same
+value returned any time you call `fromLookup` across your entire app),
+you can set the `additionalCacheKey` argument (eg, to `this.node.path` to tie it
+to the scope of the current construct)


Suggested change

If you do not want the value of the context variable to be global (ie, having the same

value returned any time you call `fromLookup` across your entire app),

you can set the `additionalCacheKey` argument (eg, to `this.node.path` to tie it

to the scope of the current construct)

To customize the cache key use the `additionalCacheKey` parameter.

This can be useful if you want to scope the context variable to a construct

(eg, using `additionalCacheKey: this.node.path`).

Feel free to improve (will need to be copied on other READMEs).

lpizzinidev · 2023-10-30T14:56:10Z

packages/aws-cdk-lib/aws-route53/test/hosted-zone-provider.test.ts

+      const stack = new cdk.Stack(app, 'TestStack', {
+        env: { account: '12345', region: 'us-east-1' },
+      });
+      const filter = { domainName: 'test.com' };


Suggested change

const filter = { domainName: 'test.com' };

const filter = {

domainName: 'test.com',

additionalCacheKey: 'cacheKey',

};

Missing parameter.

lpizzinidev · 2023-10-30T14:56:20Z

packages/aws-cdk-lib/aws-route53/test/hosted-zone-provider.test.ts

@@ -81,5 +81,43 @@ describe('hosted zone provider', () => {
      expect(fakeZoneId).toEqual(zoneId);

    });
+
+    test('HostedZoneProvider will return context values if available', () => {


Suggested change

test('HostedZoneProvider will return context values if available', () => {

test('HostedZoneProvider will return context values if available with additional cache key', () => {

luxaritas · 2023-11-16T05:30:07Z

@lpizzinidev Thanks for the suggestions - some good callouts there. Changes made, though left a couple questions about potential further adjustments.

Also given the cloud-assembly-schema is now conflicting, let me know if I should merge or rebase to latest main and regen that

lpizzinidev

Thanks for the changes.
I left some notes on possible documentation improvements.

Also given the cloud-assembly-schema is now conflicting, let me know if I should merge or rebase to latest main and regen that

You should merge main into the PR branch.

lpizzinidev · 2023-11-16T07:38:50Z

packages/aws-cdk-lib/aws-ec2/README.md

+> If you do not want the value of the context variable to be to be global
+> (ie, having the same value returned any time you call `lookup` across your entire app),
+> you can set the `additionalCacheKey` argument (eg, to `this.node.path` to tie it
+> to the scope of the current construct)


Suggested change

> If you do not want the value of the context variable to be to be global

> (ie, having the same value returned any time you call `lookup` across your entire app),

> you can set the `additionalCacheKey` argument (eg, to `this.node.path` to tie it

> to the scope of the current construct)

> To customize the cache key use the `additionalCacheKey` parameter.

> This can be useful if you want to scope the context variable to a construct

> (eg, using `additionalCacheKey: this.node.path`).

lpizzinidev · 2023-11-16T07:39:01Z

packages/aws-cdk-lib/aws-ecs/README.md

+If you do not want the value of the context variable to be global (ie, having the same
+value returned any time you call `EcsOptimizedImage.amazonLinux` across your entire app),
+you can set the `additionalCacheKey` argument (eg, to `this.node.path` to tie it
+to the scope of the current construct)


Suggested change

If you do not want the value of the context variable to be global (ie, having the same

value returned any time you call `EcsOptimizedImage.amazonLinux` across your entire app),

you can set the `additionalCacheKey` argument (eg, to `this.node.path` to tie it

to the scope of the current construct)

To customize the cache key use the `additionalCacheKey` parameter.

This can be useful if you want to scope the context variable to a construct

(eg, using `additionalCacheKey: this.node.path`).

lpizzinidev · 2023-11-16T07:40:01Z

packages/aws-cdk-lib/aws-ec2/lib/machine-image/machine-image.ts

+ * If `props.additionalCacheKey` is set, the context key uses that value as a discriminator
+ * rather than the cached value being global across all lookups


Suggested change

* If `props.additionalCacheKey` is set, the context key uses that value as a discriminator

* rather than the cached value being global across all lookups

*

* If `props.additionalCacheKey` is set, the context key uses that value as a discriminator

* rather than the cached value being global across all lookups.

lpizzinidev · 2023-11-16T07:43:30Z

packages/aws-cdk-lib/aws-ec2/README.md

@@ -744,7 +747,7 @@ If the security group ID is known and configuration details are unknown, use met
 const sg = ec2.SecurityGroup.fromLookupById(this, 'SecurityGroupLookup', 'sg-1234');
 ```

-The result of `SecurityGroup.fromLookupByName` and `SecurityGroup.fromLookupById` operations will be written to a file called `cdk.context.json`. You must commit this file to source control so that the lookup values are available in non-privileged environments such as CI build steps, and to ensure your template builds are repeatable.
+The result of `SecurityGroup.fromLookupByName` and `SecurityGroup.fromLookupById` operations will be written to a file called `cdk.context.json`. You must commit this file to source control so that the lookup values are available in non-privileged environments such as CI build steps, and to ensure your template builds are repeatable. To customize the cache key use the `additionalCacheKey` parameter. This can be useful if you want to scope the context variable to a construct (eg, using `additionalCacheKey: this.node.path`).


Suggested change

The result of `SecurityGroup.fromLookupByName` and `SecurityGroup.fromLookupById` operations will be written to a file called `cdk.context.json`. You must commit this file to source control so that the lookup values are available in non-privileged environments such as CI build steps, and to ensure your template builds are repeatable. To customize the cache key use the `additionalCacheKey` parameter. This can be useful if you want to scope the context variable to a construct (eg, using `additionalCacheKey: this.node.path`).

The result of `SecurityGroup.fromLookupByName` and `SecurityGroup.fromLookupById` operations will be

written to a file called `cdk.context.json`.

You must commit this file to source control so that the lookup values are available in non-privileged

environments such as CI build steps, and to ensure your template builds are repeatable.

To customize the cache key use the `additionalCacheKey` parameter.

This can be useful if you want to scope the context variable to a construct (eg, using `additionalCacheKey: this.node.path`).

```ts

const sg = ec2.SecurityGroup.fromLookupById(this, 'SecurityGroupLookup', 'sg-1234', this.node.path);

Formatting and example.

lpizzinidev · 2023-11-16T07:46:44Z

packages/aws-cdk-lib/aws-ec2/lib/machine-image/machine-image.ts

@@ -673,6 +690,7 @@ export class LookupMachineImage implements IMachineImage {
      props: {
        owners: this.props.owners,
        filters,
+        ...(this.props.additionalCacheKey ? { additionalCacheKey: this.props.additionalCacheKey } : {}),


Suggested change

...(this.props.additionalCacheKey ? { additionalCacheKey: this.props.additionalCacheKey } : {}),

additionalCacheKey: this.props.additionalCacheKey,

AmiContextQuery will need a new property.

lpizzinidev · 2023-11-16T07:49:29Z

packages/aws-cdk-lib/aws-ec2/lib/machine-image/machine-image.ts

+   * When the image is cached in cdk.context.json, adds an additional discriminator to the
+   * cache key so that separate lookups with the same parameters can have separate cache lifecycles


Suggested change

* When the image is cached in cdk.context.json, adds an additional discriminator to the

* cache key so that separate lookups with the same parameters can have separate cache lifecycles

* Adds an additional discriminator to the `cdk.context.json` cache key.

*

* @default - no additional cache key

Other variable comments in this PR will need an update as well.

For clarity I'm thinking "When cachedInContext is true, adds an additional discriminator..." in situations where caching does not always happen (since this variable does nothing on its own)

Hm, unfortunately cachedInContext does not always appear on the lookup parameters object. Probably better not to do it for the sake of consistency then. If anything it would be "adds an additional discriminator... if cached", but not sure how helpful that really is at that point

lpizzinidev · 2023-11-19T15:58:30Z

packages/aws-cdk-lib/aws-elasticloadbalancingv2/README.md

@@ -519,6 +519,14 @@ following lookup methods:
 - `NetworkListener.fromLookup(options)` - Look up a network load balancer
  listener.

+The result of a `fromLookup()` operation will be written to a file


This should be added at the end of the Load Balancer lookup options section with an example.

The general description is applicable to both load balancers and load balancer listeners so I think that should be in the top-level section (and I'll fix the heading level for LBL lookup options while I'm at it). Will add the examples

lpizzinidev · 2023-11-19T16:01:10Z

packages/aws-cdk-lib/aws-ssm/README.md

+To customize the cache key use the `additionalCacheKey` parameter.
+This can be useful if you want to scope the context variable to a construct 
+(eg, using `additionalCacheKey: this.node.path`).
+
+


Suggested change

To customize the cache key use the `additionalCacheKey` parameter.

This can be useful if you want to scope the context variable to a construct

(eg, using `additionalCacheKey: this.node.path`).

To customize the cache key use the `additionalCacheKey` parameter.

This can be useful if you want to scope the context variable to a construct

(eg, using `additionalCacheKey: this.node.path`).

```ts

const stringValue = ssm.StringParameter.valueFromLookup(this, '/My/Public/Parameter', this.node.path);

aws-cdk-automation · 2023-11-20T00:08:30Z

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

…-cache

luxaritas · 2023-11-20T19:24:07Z

~~For some reason the cloud-assembly-schema as I generated locally appears to have some items reordered vs when run via CI...? Not sure how to resolve, I ran yarn update-schema and its still failing~~ EDIT: Nevermind, out-of-date dependencies issue

aws-cdk-automation · 2023-11-20T19:55:09Z

AWS CodeBuild CI Report

CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
Commit ID: 1b6955c
Result: SUCCEEDED
Build Logs (available for 30 days)

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

lpizzinidev

Thanks 👍

rix0rrr

Almost there! You did a good job updating the docs explaining WHAT people can now do, but what's missing is WHY they would want to do this.

Add that and it's golden.

rix0rrr · 2023-12-20T08:54:07Z

packages/aws-cdk-lib/aws-ecs/README.md

@@ -156,6 +156,19 @@ const autoScalingGroup = new autoscaling.AutoScalingGroup(this, 'ASG', {
 });
 ```

+To customize the cache key use the `additionalCacheKey` parameter.


You need to explain WHY a user might want to do this. If I didn't know what this was already, reading this bit of the documentation certainly wouldn't help me.

rix0rrr · 2023-12-20T08:55:05Z

packages/aws-cdk-lib/aws-elasticloadbalancingv2/README.md

+```ts
+const loadBalancer = elbv2.ApplicationLoadBalancer.fromLookup(this, 'ALB', {
+  loadBalancerArn: 'arn:aws:elasticloadbalancing:us-east-2:123456789012:loadbalancer/app/my-load-balancer/1234567890123456',
+  additionalCacheKey: this.node.path,


// This will ensure that ...(what)...?

rix0rrr · 2023-12-20T16:12:29Z

packages/aws-cdk-lib/cloud-assembly-schema/lib/cloud-assembly/context-queries.ts

+   *
+   * @default - no additional cache key
+   */
+  readonly additionalCacheKey?: string;


When the context provider sends out the query, it also picks the context cache key. We can just mix the additional string into the context key; it never needs to make it to the cloud assembly as a separate field.

I believe the reason I did this was so that when the queries are constructed like so:

const attributes: cxapi.KeyContextResponse = ContextProvider.getValue(scope, { provider: cxschema.ContextProvider.KEY_PROVIDER, props: { aliasName: options.aliasName, additionalCacheKey: options.additionalCacheKey, } as cxschema.KeyContextQuery, ... });

it would be surfaced as a valid member of the object passed to props. You're saying this is not necessary?

aws-cdk-automation · 2024-01-11T00:08:28Z

This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week.

luxaritas · 2024-01-11T00:10:04Z

@rix0rrr Could you provide clarification on the comment above so that I can finish this up? Thanks!

aws-cdk-automation · 2024-01-19T00:08:22Z

This PR has been deemed to be abandoned, and will be automatically closed. Please create a new PR for these changes if you think this decision has been made in error.

mergify · 2024-01-19T00:11:14Z

⚠️ The sha of the head commit of this PR conflicts with #28766. Mergify cannot evaluate rules on this PR. ⚠️

aws-cdk-automation requested a review from a team September 2, 2023 03:46

github-actions bot added beginning-contributor [Pilot] contributed between 0-2 PRs to the CDK effort/medium Medium work item – several days of effort feature-request A feature should be added or improved. p2 labels Sep 2, 2023

aws-cdk-automation previously requested changes Sep 2, 2023

View reviewed changes

aws-cdk-automation added the pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member. label Sep 2, 2023

luxaritas added 6 commits September 6, 2023 18:16

feat(core): Support linking cdk context values to scope

ec846d2

linkContextToScope should be passed to LookupMachineImage props not g…

00cc494

…etImage

Fix missing passthroughs of linkContextToScope

015bad1

Add integration test for cached machine image lookup

d8d27f9

Fix default in AmazonLinuxImageSsmParameterBase

ea2d380

Update snapshot

edbccad

luxaritas force-pushed the scope-local-context-cache branch from d6f96bd to edbccad Compare September 6, 2023 22:16

rix0rrr previously requested changes Sep 19, 2023

View reviewed changes

aws-cdk-automation removed the pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member. label Sep 19, 2023

Use explicit cache key instead of opting in to scope key

285fa90

Fix unit tests

bf8c6c1

aws-cdk-automation added the pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member. label Sep 19, 2023

luxaritas changed the title ~~feat(core): support linking cdk context values to scope~~ feat(core): support adding additional cache key to cdk context values Sep 19, 2023

github-actions bot mentioned this pull request Oct 1, 2023

Monthly PRs metrics report - Sep 2023 #27368

Closed

lpizzinidev suggested changes Oct 30, 2023

View reviewed changes

luxaritas added 2 commits November 16, 2023 03:39

Remove dead imports

4608dba

Integ structure

925bd48

aws-cdk-automation removed the pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member. label Nov 16, 2023

luxaritas added 8 commits November 16, 2023 04:02

Correct comment

bc36cab

Simplify references from props

bf503e8

No need to spread

b783667

Revert format change

0b39809

Revert function signature change

0e6cfb5

Remove more spreads, add to interfaces

7dc9501

Fix unit test

f7bcd97

update schema

8c508ab

lpizzinidev suggested changes Nov 19, 2023

View reviewed changes

luxaritas added 3 commits November 20, 2023 10:43

Merge remote-tracking branch 'upstream/main' into scope-local-context…

c093baf

…-cache

Docs improvements

8397e44

Regen schema from main

4cdc802

update-schema

1b6955c

lpizzinidev approved these changes Nov 21, 2023

View reviewed changes

aws-cdk-automation added the pr/needs-maintainer-review This PR needs a review from a Core Team Member label Nov 21, 2023

rix0rrr requested changes Dec 20, 2023

View reviewed changes

aws-cdk-automation removed the pr/needs-maintainer-review This PR needs a review from a Core Team Member label Dec 20, 2023

rix0rrr requested changes Dec 20, 2023

View reviewed changes

aws-cdk-automation added the closed-for-staleness This issue was automatically closed because it hadn't received any attention in a while. label Jan 19, 2024

aws-cdk-automation closed this Jan 19, 2024

luxaritas mentioned this pull request Jan 19, 2024

feat(core): support adding additional cache key to cdk context values #28766

Closed

	if (props.additionalCacheKey) this.additionalCacheKey = props.additionalCacheKey;
	this.additionalCacheKey = props.additionalCacheKey;

	if (props?.additionalCacheKey) this.additionalCacheKey = props.additionalCacheKey;
	this.additionalCacheKey = props?.additionalCacheKey;

	function lookupImage(scope: Construct, cachedInContext: boolean, parameterName: string, additionalCacheKey?: string) {
	function lookupImage(scope: Construct, cachedInContext?: boolean, parameterName: string, additionalCacheKey?: string) {

	...(options.additionalCacheKey ? { additionalCacheKey: options.additionalCacheKey } : {}),
	additionalCacheKey: options.additionalCacheKey,

	test('HostedZoneProvider will return context values if available', () => {
	test('HostedZoneProvider will return context values if available with additional cache key', () => {

		* If `props.additionalCacheKey` is set, the context key uses that value as a discriminator
		* rather than the cached value being global across all lookups

	...(this.props.additionalCacheKey ? { additionalCacheKey: this.props.additionalCacheKey } : {}),
	additionalCacheKey: this.props.additionalCacheKey,

		* When the image is cached in cdk.context.json, adds an additional discriminator to the
		* cache key so that separate lookups with the same parameters can have separate cache lifecycles

feat(core): support adding additional cache key to cdk context values #26984

feat(core): support adding additional cache key to cdk context values #26984

Conversation

luxaritas commented Sep 2, 2023 • edited Loading

aws-cdk-automation left a comment

Choose a reason for hiding this comment

luxaritas commented Sep 2, 2023 • edited Loading

luxaritas commented Sep 2, 2023

rix0rrr left a comment

Choose a reason for hiding this comment

luxaritas commented Sep 19, 2023 • edited Loading

luxaritas commented Sep 19, 2023

lpizzinidev left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

luxaritas Nov 16, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

luxaritas commented Nov 16, 2023

lpizzinidev left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

luxaritas Nov 20, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aws-cdk-automation commented Nov 20, 2023

luxaritas commented Nov 20, 2023 • edited Loading

aws-cdk-automation commented Nov 20, 2023

AWS CodeBuild CI Report

lpizzinidev left a comment

Choose a reason for hiding this comment

rix0rrr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

luxaritas Dec 20, 2023 • edited Loading

Choose a reason for hiding this comment

aws-cdk-automation commented Jan 11, 2024

luxaritas commented Jan 11, 2024

aws-cdk-automation commented Jan 19, 2024

mergify bot commented Jan 19, 2024

luxaritas commented Sep 2, 2023 •

edited

Loading

luxaritas commented Sep 2, 2023 •

edited

Loading

luxaritas commented Sep 19, 2023 •

edited

Loading

luxaritas Nov 16, 2023 •

edited

Loading

luxaritas Nov 20, 2023 •

edited

Loading

luxaritas commented Nov 20, 2023 •

edited

Loading

luxaritas Dec 20, 2023 •

edited

Loading