[riff-raff-yaml-file/deployments/lambda] the contentDirectory field should vary based on lambda.withoutFilePrefix

[twrichards]

The withoutFilePrefix prop of the lambda impacts the bucket key prefix used in riff-raff steps, but the contentDirectory remains pegged to the value of app...

cdk/src/riff-raff-yaml-file/deployments/lambda.ts

Line 53 in ec0fb85

contentDirectory: app,

...and as such one can't have multiple lambdas sharing the same ZIP

[akash1810]

I think this sounds sensible.

...and as such one can't have multiple lambdas sharing the same ZIP

Could you link to an example where this is necessary? Worth noting GuCDK should provide the paved path by default, and we should prefer to deviate via escape hatches. Hopefully any linked example can help us decide if this behaviour is part of the paved path.

[twrichards]

Could you link to an example where this is necessary?

It's for guardian/newswires#83 which is very much a WIP - we generate a lambda (plus supporting SQS etc) for each item in a list (a list of agencies/suppliers). We must vary the app otherwise riff-raff can't find by tag, but that in turn means its looking for the zip in a different directory even though all the lambda code is bundled in the same zip... hence was exploring the withoutFilePrefix but then got stuck since contentDirectory still derives from app. I could explore producing a separate zip for each lambda (even though 90% of the weighty code will be identical in each) or could even script the duplication of the zip for each lambda to satisfy the defaults in GuCDK.

Worth noting GuCDK should provide the paved path by default, and we should prefer to deviate via escape hatches. Hopefully any linked example can help us decide if this behaviour is part of the paved path.

As I understand it there is no way to access the riff-raff yaml direct from the GuStack is there? perhaps that's the solution? (you may also spot a TODO about creating a riff-raff dependency between multiple cfn deployments (as one relies on the resources belonging to the other, but as it stands they deploy in parallel)

[akash1810]

Anecdotally, I think your example is the exception across the estate - I'd love to talk about it to learn more.

As I understand it there is no way to access the riff-raff yaml direct from the GuStack is there?

The changes in #2042 enabled this. The description of that PR shows an example of adding a deployment, but something like this should also be possible to edit a deployment:

// file:cdk/bin.ts

import type { RiffRaffDeploymentName, RiffRaffDeploymentProps } from "@guardian/cdk/lib/riff-raff-yaml-file/types";

const riffraff = new RiffRaffYamlFile(app);
const contentDirectory = "my-static-directory";

riffraff.riffRaffYaml.deployments.forEach((value: RiffRaffDeploymentProps, key: RiffRaffDeploymentName) => {
  if (value.type === "aws-lambda") {
    riffraff.riffRaffYaml.deployments.set(key, {
      ...value,
      contentDirectory,
    });
  }
});

Or something more functional with .filter then .forEach.

I'd suggest trying that first. If it becomes unmaintainable, let's make changes to GuCDK. WDYT?

[twrichards]

Thank you @akash1810, I've implemented as you've suggested in guardian/newswires@32d6100 which works (you can see via the riff-raff snapshot testing 😍).

Closing this issue since I'm now unblocked and agree with the preference for escape hatch for this unique use-case.