With #2919 having demonstrated that a change unrelated to serverless operation can inadvertently impact serverless operation, we ought to proactively prevent any future similar issue from happening by hardening the agent's release process.
Here are at least 2 complementary ideas that can be explored:
Additional testing prior to release: We could potentially modify the publish-layers.sh script described in the layers README to produce .zips but skip their publication. The zips could then be incorporated into a CDK (probably, though CFN or TF might work too) based workflow that would spin up a Ruby Lambda function with a .zip based layer applied. The function could then be invoked and NRQL used to confirm a successful invocation.
Additional testing post release: Immediately after an agent release has produced newly published Lambda layers, those layers could be applied to a Ruby Lambda function and tested by invoking the function and performing a NRQL query to confirm successful invocation.
workato-integration[bot]
commented
4 weeks ago
With #2919 having demonstrated that a change unrelated to serverless operation can inadvertently impact serverless operation, we ought to proactively prevent any future similar issue from happening by hardening the agent's release process.
Here are at least 2 complementary ideas that can be explored:
publish-layers.shscript described in the layers README to produce .zips but skip their publication. The zips could then be incorporated into a CDK (probably, though CFN or TF might work too) based workflow that would spin up a Ruby Lambda function with a .zip based layer applied. The function could then be invoked and NRQL used to confirm a successful invocation.