feat: add parameter helper functions on GuStack

[akash1810]

What does this change?

#65, but for parameters.

Helper functions to get/set parameters on the GuStack. An Error is thrown when getting a parameter that hasn't been set; this is to catch the error at compile time.

This is useful for when a construct reads from a parameter but isn't responsible for adding the parameter. For example, reading the DistributionBucketName param in the user data, where DistributionBucketName is added by GuGetDistributablePolicy via GuInstanceRole. One such example can be seen here.

Does this change require changes to existing projects or CDK CLI?

No.

How to test

Observe CI.

How can we measure success?

It is simpler to share parameters across constructs.

Have we considered potential risks?

n/a

[jorgeazevedo]

Left some comments in the diff

[jamie-lynch]

Definitely one for discussion. This is quite similar to something we had right at the start which we then moved away from. I like this general approach in theory but we didn't quite get it right the first time so resorted to just using const parameters = { ... } but if there's now another reason to go back to this then I'd be keen to explore it again.

[akash1810]

I think I have a use case for this! 🎉

A UserData construct will look something like this:

#!/bin/bash -ev
aws --region ${this.region} s3 cp s3://${distributionBucketNameParam.valueAsString}/${this.stack}/${this.stage}/${this.app}/${this.app}.deb /tmp/
dpkg -i /tmp/${this.app}.deb

distributionBucketNameParam is a parameter added to the stack from GuGetDistributablePolicy, and we'd need a way of accessing it from within the UserData construct.

[akash1810]

Another use case is then you want to have multiple ASGs in a stack. Currently an ASG will bring an AMI parameter with it. This parameter is called "AMI" by default. If we try to add two ASGs to a stack, then we'll attempt to add the same parameter twice and an exception is thrown. If we have a helper function to manage params, then we can do some validation.

I'll revive this branch today.

[jacobwinch]

Currently an ASG will bring an AMI parameter with it. This parameter is called "AMI" by default.

@akash1810 FYI I think it's possible to override this behaviour.

[akash1810]

@akash1810 FYI I think it's possible to override this behaviour.

Ah! I keep forgetting about this!

I don't think this'll allow a single AMI param to be used in multiple ASGs however as a similar exception noted above will be thrown?

Sharing AMIs across ASGs is fairly common and reasonable; here's an example from Grid the single param AmiId is used in 9 ASGs.

[jacobwinch]

I don't think this'll allow a single AMI param to be used in multiple ASGs however as a similar exception noted above will be thrown?

I haven't tested this, but I think this might work?

const mySharedAmi = new GuAmiParameter(stack, "MyAMI", {})

const myFirstAsg = new GuAutoScalingGroup(stack, "AutoscalingGroup", {
      // firstAsgProps
      imageId: mySharedAmi,
});

const mySecondAsg = new GuAutoScalingGroup(stack, "AutoscalingGroup", {
      // secondAsgProps
      imageId: mySharedAmi,
});

[akash1810]

Oh lovely! Yeah that does work! The tests fail due to InstanceType being declared twice, but we can do a similar trick there too.

[akash1810]

Merging w/out full approval as @jorgeazevedo is currently on leave.