tests(parameters): integration tests for AppConfigProvider

[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 AppConfig parameters. The function code uses the Parameters utility to retrieve the 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 stack creates an AppConfig application and environment, and then creates a number configuration profiles, each with a different type of parameter.

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:

• Free-form JSON
• Free-form YAML
• 2x Free-form plain text
• Feature flag JSON

These parameters allow to retrieve the values and test some transformations.

The tests are:

Test 1

get a single parameter by name with default options

Test 2

get multiple parameters by path with default options

Test 3

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 4

get multiple parameters by path with decrypt

Test 5

get multiple parameters by name with default options

Test 6

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

Test 7

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: #1242

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]

This is not very elegant, but I was getting race conditions on the deployments without.

All these parameters use the same AppConfig application & environment and generally speaking, for each pair deployments use sequential numbers/ids. Deploying them all at once caused almost consistently CloudFormation errors when trying to deploy more than 3 configs.

With these lines we enforce the deployments to happen sequentially.

[am29d]

I removed this chained dependencies and could not reproduce the described behaviour. Can you rerun and double check that the previous test run stack does not exist?

This is because all deployment are running within the same app. Running one deployment per application is possible, we can spawn new app for each createAppConfigConfigurationProfile call. What do you think?

Edit: creating environment is far easier than application.

[dreamorosi]

We could do that yes, however we would move the "ugly" part to the function code of the test instead because we would have to create a dedicated instance of AppConfigProvider for each application.

Right now creating a provider requires to do this:

const provider = new AppConfigProvider({ application: 'something', environment: 'something' });

So if we have multiple environments/applications, we'll need a provider for each pair.

What do you think?

[am29d]

I have moved the environment to the inner part of the resource creation and 10 tests were green, but I was only lucky, the race condition remains (tested today again). Let's keep the workaround with a comment.

[dreamorosi]

Done, I have added a short paragraph in the comment section of this test to explain & document this.

[dreamorosi]

Hi @am29d, review appreciated here as well.

Likely will have merge conflicts to resolve once we merge #1257, but when you have bandwidth we can start reviewing this one too

[dreamorosi]

E2E test run after merging the conflicts:

[am29d]

I removed this chained dependencies and could not reproduce the described behaviour. Can you rerun and double check that the previous test run stack does not exist?

This is because all deployment are running within the same app. Running one deployment per application is possible, we can spawn new app for each createAppConfigConfigurationProfile call. What do you think?

Edit: creating environment is far easier than application.