Support deploying Lambda functions depending on Lambda layers

[t-kikuc]

What this PR does / why we need it:

Enabled to deploy Lambda functions which use layers.

The config is like below:

function.yaml

apiVersion: pipecd.dev/v1beta1
kind: LambdaFunction
spec:
  ...
  layers: # NEW ATTRIBUTE.  not necessary.
    - arn:aws:lambda:REGION:ACCOUNT_ID:layer:layer-A:3
    - arn:aws:lambda:REGION:ACCOUNT_ID:layer:layer-B:1

Which issue(s) this PR fixes:

Fixes #4803

Does this PR introduce a user-facing change?: yes (addition only)

• How are users affected by this change: add attributes if needed
• Is this breaking change: no
• How to migrate (if breaking change): no

[codecov]

Codecov Report

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

Project coverage is 30.62%. Comparing base (9a298a8) to head (e712366).
Report is 1 commits behind head on master.

Files	Patch %	Lines
pkg/app/piped/platformprovider/lambda/client.go	0.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4805      +/-   ##
==========================================
- Coverage   30.64%   30.62%   -0.02%     
==========================================
  Files         227      227              
  Lines       27207    27210       +3     
==========================================
- Hits         8337     8333       -4     
- Misses      18210    18216       +6     
- Partials      660      661       +1     

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

[t-kikuc]

/review

[github-actions]

PR Analysis

Main theme

Support for AWS Lambda Layers feature in Lambda Function deployment

PR summary

The PR adds support for specifying AWS Lambda Layers for Lambda functions in the corresponding deployment platform provider within the application. This enables users to include additional code or libraries as layers in AWS Lambda deployment manifests.

Type of PR

Enhancement

PR Feedback:

General suggestions

The PR looks good in aiming to add support for AWS Lambda Layers, which is a significant feature for Lambda functions. It allows reusability and proper management of common dependencies and libraries. One important aspect to consider is to validate if the ARNs provided for the layers are well-formed and accessible by the Lambda function, which could be either part of the client-side logic or left to AWS Lambda to validate when deploying the function.

Code feedback

• relevant file: pkg/app/piped/platformprovider/lambda/client.go
  suggestion: |-
  Add validation for the Layers field before making the API call to create or update the Lambda function. It's important to verify that the layer ARNs provided follow the correct ARN format and that there aren't any duplicates in the list. This pre-validation can avoid failed deployment attempts due to format issues and to ensure idempotent operations.

  if err := validateLayerARNs(fm.Spec.Layers); err != nil {
      return err
  }

  (important)
  relevant line: + Layers: fm.Spec.Layers,

• relevant file: pkg/app/piped/platformprovider/lambda/function.go
  suggestion: |-
  To improve the self-documentation of the Layers field in the FunctionManifestSpec struct, consider adding a validation note or an example directly in the comments. This could facilitate understanding for the developers or users configuring Lambda functions using this platform provider.

  // Each layer should be specified as an ARN: "arn:aws:lambda:<region>:<account-id>:layer:<layer-name>:<layer-version>"

  (medium)
  relevant line: + Layers []string \json:"layers,omitempty"``

Security concerns:

no
There are no direct security implications in the added code itself, as it just passes the Layer ARN information through to the AWS Lambda API. However, security needs to be considered when managing Lambda Layer versions and access to ensure that only trusted code is executed.

[khanhtc1202]

Nice improvement 👍

[ffjlabo]

Sorry to be late 🙏