[lambda][flare] Send minimal Lambda config data to Datadog

[nhulston]

What and why?

This PR adds functionality to the datadog-ci lambda flare command to automatically collect useful information from customers to help Datadog support resolve customer issues. This PR only adds functionality for getting and sending AWS Lambda function configuration for a single Lambda function/region to the support staff.

Future PRs aim to:

• Support multiple Lambda functions/regions
• Gather AWS CloudWatch logs
• Add an interactive mode
• Enable support ticket creation via the command
• And more

How?

An example command would be lambda flare -f function-name -r us-east-1 -c 1234567 -e [email protected]

This PR allows sending function configuration to the support staff through several steps:

1. Checks for required flags and environment variables: Datadog API key, AWS lambda function name or ARN, Datadog case ID (to send the config file to), and customer email
2. Accepts the following flags: --dry, --function, --region, --case-id, --email (and their shorthands -d, -f, -r, -c, -e). The --dry flag enables a mode where the config.json is printed but not saved as a file or sent.

3. Fetches AWS credentials using the getAWSCredentials() or requestAWSCredentials() functions:

   datadog-ci/src/commands/lambda/functions/commons.ts

   Lines 234 to 249 in 08ea2aa

   	export const getAWSCredentials = async () => {
   	const provider = fromNodeProviderChain()
   	try {
   	const credentials = await provider()
   	return credentials
   	} catch (err) {
   	if (err instanceof Error) {
   	if (err.name === CredentialsProviderError.name) {
   	return undefined
   	}
   	throw Error(`Couldn't fetch AWS credentials. ${err.message}`)
   	}
   	}
   	}

   and https:/DataDog/datadog-ci/blob/01ffb226b154935c71e4618d5a53e24414c1971a/src/commands/lambda/prompt.ts#L215-L22
4. Retrieves and prints Lambda function config from AWS using getLambdaFunctionConfig():

   datadog-ci/src/commands/lambda/functions/commons.ts

   Lines 364 to 386 in 08ea2aa

   	/**
   	* Call the aws-sdk Lambda api to get a Function given
   	* an ARN and then return its Configuration.
   	*
   	* @param lambdaClient an instance of LambdaClient.
   	* @param functionARN a string, can be Function ARN, Partial ARN, or a Function Name.
   	* @returns the Lambda FunctionConfiguration of the given ARN.
   	*/
   	export const getLambdaFunctionConfig = async (
   	lambdaClient: LambdaClient,
   	functionARN: string
   	): Promise<LFunctionConfiguration> => {
   	const params: GetFunctionCommandInput = {
   	FunctionName: functionARN,
   	}
   	const command = new GetFunctionCommand(params)
   	const response = await lambdaClient.send(command)
   	// AWS typescript API is slightly mistyped, adds undefineds where
   	// there shouldn't be.
   	const config = response.Configuration!
   	return config
   	}

5. Saves the config file in .datadog-ci/config.json using the fs package
6. Zips the .datadog-ci folder using the jszip package. Future PRs will save multiple files, so jszip is required to zip an entire directory
7. Sends the zipped file to Datadog support via a POST request defined here: https:/DataDog/dogweb/pull/96288
8. Deletes the zipped file and folder contents after being sent to support

These changes provide a robust foundation for future PRs, ensuring efficient implementation of additional features.

Review checklist

• Feature or bugfix MUST have appropriate tests (unit, integration)

[datadog-datadog-prod-us1]

Datadog Report

Branch report: nicholas.hulston/serverless-flare/flare-subcommand
Commit report: 1bb8b07

✅ datadog-ci-tests: 0 Failed, 0 New Flaky, 663 Passed, 0 Skipped, 48.22s Wall Time

[duncanista]

Couple comments

[duncanista]

Left some comments

[juan-fernandez]

I lack the context for reviewing the lambda bit but do we need jszip? Have we tried using zlib?

[juan-fernandez]

do we want to hardcode a staging URL like this?

[duncanista]

Hey @juan-fernandez, we will hard code it for staging in the meantime. We will not merge this to the main branch until we have the right endpoint merged in production.

We will bring another PR to update this to the user specific site endpoint in the future, wdyt?

[juan-fernandez]

couldn't we use zlib that is native? We wouldn't need a new dependency then.

[nhulston]

Thanks for the review, I will look into using zlib instead

[nhulston]

Hey @juan-fernandez
Looks like zlib only supports zipping single files. While this would work for this PR, we do plan on zipping multiple files in the near future, so we would eventually need a new dependency like jszip.

What do you think?

Edit: I meant jszip not fszip!

[duncanista]

@nhulston do you mean jszip?

@juan-fernandez I'd normally go for the zlib approach too, when I researched on this, it seemed that we needed more packages to compress folders (tar and fstream). By using zlib and its dependencies for our use case, previously mentioned, we would be using 550~600 kB less than if we used jszip.

It seems that change of implementation might be trivial. But of course, this could be refactored in the future if package size is a problem. This would also not be merged directly into main since our working branch serverless-flare is still a WIP before its first release.

What do you think @juan-fernandez?

[duncanista]

Great first PR!