tests(parameters): integration tests for SSMProvider

[dreamorosi]

Description of your changes

This PR introduces the test suite that runs integration tests on the SSMProvider which is part of the upcoming Parameters utility. The PR also extends the ResourceAccessGranter helper to add compatibility for SSM.

Test suite

This test suite deploys a CDK stack with a Lambda function and a number of SSM parameters. The function code uses the Parameters utility to retrieve the SSM parameters. It then logs the values to CloudWatch Logs as JSON objects.

Once the stack is deployed, the Lambda function is invoked and the CloudWatch Logs are retrieved. The logs are then parsed and the values are checked against the expected values for each test case.

The parameters created are:

• Name: param/a - Value: foo
• Name: param/b - Value: bar
• Name: param-encrypted/a - Value: foo-encrypted
• Name: param-encrypted/b - Value: bar-encrypted

These parameters allow to retrieve one or more parameters both by name and by path, as well as mixing encrypted and unencrypted parameters.

The tests are:

Test 1

get a single parameter by name with default options

Test 2

get a single parameter by name with decrypt

Test 3

get multiple parameters by path with default options

Test 4

get multiple parameters by path recursively (aka. get all parameters under a path recursively) i.e. given /param, retrieve /param/get/a and /param/get/b (note path depth)

Test 5

get multiple parameters by path with decrypt

Test 6

get multiple parameters by name with default options

Test 7

get multiple parameters by name, some of them encrypted and some not

Test 8

get parameter twice with middleware, which counts the number of requests, we check later if we only called SSM API once

Test 9

get parameter twice, but force fetch 2nd time, we count number of SDK requests and check that we made two API calls

How to verify this change

Given that the integration tests are not yet hooked up to the GitHub workflow that runs them on GitHub, at the moment the only way to test this is to checkout the repo locally and then run: npm run test:e2e:nodejs18x -w packages/parameters.

The command above will run the tests on your currently logged in AWS account and use the Node.js 18 runtime.

Below a screenshot of the result as run on my machine:

Related issues, RFCs

Issue number: #1240

PR status

Is this ready for review?: YES
Is it a breaking change?: NO

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
• I have made corresponding changes to the examples
• My changes generate no new warnings
• The code coverage hasn't decreased
• I have added tests that prove my change is effective and works
• New and existing unit tests pass locally and in Github Actions
• Any dependent changes have been merged and published
• The PR title follows the conventional commit semantics

Breaking change checklist

• 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.

[dreamorosi]

Hi @am29d, review appreciated whenever you have bandwidth

[am29d]

Looks great! Left few minor observations.

[dreamorosi]

Thank you for the review & comments Alex, appreciate it.

I've addressed all of them and made changes in line with the decisions we took in each one.

I have also run the e2e tests again:

Note that I will address the topic of explaining the behavior of each public method (in relation to the options order) in #1283

[am29d]

LGTM, we are good.