v2.5.0
Summary
Summary: Allow to assign an environment name to each RunsOn stack. Allow to specify VPC CIDR block and export outputs to facilitate VPC peering connections. Allow to set custom tags on instances.
Potentially breaking changes
If you have set the Private parameter to true in the CloudFormation template, the behaviour has changed:
- The stack will now create only 1 managed NAT gateway (instead of 3) when enabling
Privatemode, to save on costs. - Also, runners will be launched in the private subnets only if the label
private=trueis present in theruns-on:definition. This way, runners will launch in the public subnets by default, and you can selectively use the private subnet (to get the egress static IP) for specific workflows. This saves on NAT bandwidth costs since most workflows don't need static IP.
Features
- Allow assigning an environment name to a RunsOn stack (default
production), which can then be targeted by using theenvlabel in the workflow. This allows setting up multiple isolated RunsOn stacks to handle environments such asstagingetc. with different IAM permissions or configurations. Fixes #120. - Allow specifying a custom VPC CIDR block when creating the stack. This helps if you plan on establishing VPC peering connections with your RunsOn runners. Note that updating this parameter for existing stacks is not recommended. You should create a new stack instead, and remove the old one. Fixes #114.
- Provide a CloudFormation template to facilitate the establishment of a VPC peering connection between RunsOn's VPC, and a destination VPC.
- Allow setting custom tags on the instances launched by RunsOn (
RunnerCustomTagsCloudFormation parameter). Fixes #119.