Hello again,

Great module, it's working really well so far from our testing.

One thing that confuses me slightly is that as far as I can tell, you are expected to deploy many stacks of this module if you are making use of runner groups, 1 stack per runner group. The GitHub Actions platform offers few server-side security features currently and so it's difficult to not make use of runner groups if security is important to your organisation. As a result of this, you often end up with multiple runner groups being implemented for any given environment (production being the most common). The Environment input causes problems because it not only gets used to namespace the stack, but also to create / set a tag called Environment. If you have to deploy multiple instances of this stack the set value for this tag can't be what someone would traditionally call an "environment" e.g. "production", as it needs to be unique to namespace the instance from other instances of the stack. Furthermore, the tag Environment is extremely common and so you end up with a clash between your internal tagging standard, and this modules use of the tag, both in terms of what this tag ends up representing as well as a duplicate key clash.

Would it be better to rename this key to Namespace and have the tag it creates also have the key Namespace so that people can still apply an Environment tag as well as having its value make a bit more sense. Perhaps it seems like semantics but I would think Environment is an extremely common key resulting in a clash in lots of organisations. Namespace might also cause clashing issues but I would think for fewer. You could use something a bit more utilitarian instead like ActionsStackPrefix or even continue with using Environment but have the tag creation as a configurable option if it isn't used by the module for something? If none of those work perhaps add a namespace to this tags key to differentiate it from an internal Environment tag like philips-labs/Environment? You could argue that you should namespace your internal tags however that is much harder to implement once a strategy is in place already.

Interested to hear your thoughts if this is a problem from your perspective. This modules concept of an Environment seems very blurry to me if you need to deploy multiple copies of the stack to support multiple runner groups. Perhaps in isolation it makes sense but when deploying this solution into an AWS organisation or running multiple instances of this stack due to the need for multiple runner groups to target the same "environment" e.g. production, this modules concept of an Environment breaks down.