chore(ci): add canary to layer deployment

[am29d]

Description of your changes

This PR adds a canary step after the layer deployment for beta and prod. I have also extended the content of the layer by adding commons and parameters. This needs to be extended in the future, once we a utility is GA.

Related issues, RFCs

Issue number: closes #1355

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my change is effective and works
• The PR title follows the conventional commit semantics

Breaking change checklist

Is it a breaking change?: NO

• I have documented the migration process
• I have added, implemented necessary warnings (if it can live side by side)

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[dreamorosi]

Thank you for working on this PR and providing a fix so quickly.

The PR looks good, I have left a comment and a couple of questions.

Another thing that I'm wondering: is there an opportunity for us to reuse/build on the function we already have for the layers e2e tests (here)? Looking at them they seem to do similar things (excluding the Parameters related import that you just added).
If yes, then less code for us to maintain.

[dreamorosi]

Nit: if we are defining the executionRole only to attach a policy below, maybe we can instead do:

canaryFunction.role?.attachInlinePolicy(
  new iam.Policy(this, 'list-buckets-policy', {
    statements: [
      new PolicyStatement({
        actions: ['lambda:GetFunction'],
        resources: ['*'],
        effect: Effect.ALLOW,
      })
    ],
  }),
);

This way we let CDK manage the role now & in future versions.

[am29d]

This made me realise that the role is not required any more, so removing.

[dreamorosi]

Suggested change

	const ssmProvider = new SSMProvider();
	new SSMProvider();

[dreamorosi]

So we can remove the Eslint ignore.

[dreamorosi]

Alternatively, let's actually retrieve a parameter - I see that the stack has one.

[am29d]

we can fetch the layer ARN parameter, good point

[am29d]

I changed my mind, I only create the provider. It'd add otherwise unnecessary complexity to change the tests with parameters.

[dreamorosi]

Should we / is it worth it to use different runtimes? Is it overkill to do so here?

If we decide to go with only one, should we use the oldest runtime instead? The reasoning behind using oldest is that we already develop using the latest, so it's more likely we'll have caught issues with that.

On the other hand, that might be a concern for e2e tests and not for this stage.

Thoughts?

[am29d]

I am indifferent, the e2e tests for layer should ensure it works with all supported runtimes. Using oldest is a better choice as you mentioned.

[am29d]

Another thing that I'm wondering: is there an opportunity for us to reuse/build on the function we already have for the layers e2e tests (here)? Looking at them they seem to do similar things (excluding the Parameters related import that you just added). If yes, then less code for us to maintain.

You are right, I can merge both by adding parameters fetch. The e2e function has also version check, which I forgot.

[dreamorosi]

Assuming that we don't have a way to test this until we actually make a release, looks good to me!