Enable access to SHA256 of built Lambda zipfile

[blimmer]

I would like to be able to access the SHA256 hash of the zipfile created by a Lambda function's build process, whether built through Code.fromAsset or via a higher-level package like aws-lambda-nodejs.

Use Case

My specific use-case has to do with Lambda@Edge functions (see also #1575), and the requirement that those functions have a deployed version. However, this request would benefit any user who wanted a new lambda Version created when they change their Lambda's source code.

From the searching I've done, it appears that some folks manually read in the contents of the lambda function and create a hash manually, like this:

const sha256 = require('sha256-file');
const version = lambda.addVersion(':sha256:' + sha256('./lambda/index.js'));

However, with the introduction of additional build functionality via aws-lambda-nodejs, this process starts to break down. Imagine updating your lambda's dependencies via package.json or package-lock.json. The source file (e.g. index.ts) does not get updated, but the resultant zipfile would get a new hash, with the new dependencies. So, what you'd really want in this case, is access to the SHA256 of the zipfile after the build process has completed.

Proposed Solution

I could see allowing access to the source hash via a property on the lambda function. For instance:

const myLambda = new lambda.NodejsFunction(this, 'MyFunction', {
  entry: path.join(__dirname, 'my-lambda', 'index.ts')
  handler: 'myExportedFunc'
});

const version = new lambda.Version(this, `Version-${myLamda.zipFile.sha256}`, {
  lambda: myLambda
});

// Reference `version` later on, like in the CloudFront Lambda@Edge config

The only issue I see right away is when the lambda code is not generated locally, like when it references an S3 object. In that case, maybe we'd need to throw a runtime exception? I'm not 100% sure.

Other

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[blimmer]

In the meantime, I worked around the problem in a way that works, but is completely outside of the CDK environment, relying on node fs and crypto methods.

Given a filesystem that looks like this:

.
├── my-lambda
│   ├── index.ts
│   ├── package-lock.json
│   └── package.json
└── my-lambda-stack.ts

I can ascertain the SHA256 like this in my stack.

export class MyLambdaStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps)  {
    super(scope, id, props);

    this.createLambda()
  }

  private createLambda() {
    const myLambdaPath = path.join(__dirname, "my-lambda");
    const buildDir = path.join(myLambdaPath, ".build");
    const filename = "index";
    const lambda = new NodejsFunction(this, "my-lambda", {
      entry: path.join(myLambdaPath, `${filename}.ts`),
      runtime: Runtime.NODEJS_12_X,
      handler: "handler",
      minify: true,
      buildDir,
    });

    const builtLambdaSha256 = this.getBuiltLambdaSha256(buildDir, filename);

    return new Version(this, `LambdaVersion-${builtLambdaSha256}`, {
      lambda,
    });
  }

  private getBuiltLambdaSha256(buildDir: string, filename: string): string {
    const buildDirectories = fs.readdirSync(buildDir);

    if (buildDirectories.length > 1) {
      // If you're a future dev and encounter this error, you have a few options.
      // - You could try to find the "latest" directory via timestamp.
      // - If this GitHub issue (https://github.com/aws/aws-cdk/issues/6750) has been addressed, you might be able to get rid of this entirely.
      throw new Error(
        "Cannot auto-version lambda. At the time of writing, Parcel only left one folder in the build directory, so we could determine the SHA of the most recently built file. Now there are multiple directories in the build dir. See code comments for ideas on how to fix this.",
      );
    }

    const builtLambdaFile = path.join(buildDir, buildDirectories[0], `${filename}.js`);
    const fileContents = fs.readFileSync(builtLambdaFile);
    return crypto
      .createHash("sha256")
      .update(fileContents)
      .digest("hex");
  }
}

[blimmer]

Thanks @eladb - I upgraded to 1.32.x today and this worked perfectly!