Add support for `global` in the env position of samconfig.toml files

[softprops]

Describe your idea/feature/enhancement

I wish SAM CLI would support a samconfig.toml file that requires less repetition across env. I believe it could do that leveraging its existing notion of global put into the env position of samconfig.toml tables

Proposal

Today samconfig.toml files supports a notion of a default env and global command context and a section

As mentioned under the precedence rules documentation, you can leverage a technique to reduce repetition on a per env basis across different commands for that env using the global alias in the command context position.

 [prod.global.parameters]
 stack_name = "common-stack"

 [prod.deploy.parameters]
 stack_name = "my-app-stack"

However, you can not leverage this to reduce repetition across envs.

A common case I have is a separate deployment table to support multiple deployment envs

version = 1

[dev-us-east-1.deploy.params]
stack_name = "xxx-dev"
s3_bucket = "sam-artifacts-xxx-us-east-1"
region = "us-east-1"
fail_on_empty_changeset = false
capabilities = "CAPABILITY_IAM"

[prod-us-east-1.deploy.params]
stack_name = "xxx-prod"
s3_bucket = "sam-artifacts-xxx-us-east-1"
region = "us-east-1"
fail_on_empty_changeset = false
capabilities = "CAPABILITY_IAM"

[dev-us-west-2.deploy.params]
stack_name = "xxx-dev"
s3_bucket = "sam-artifacts-xxx-us-east-1"
region = "us-west-2"
fail_on_empty_changeset = false
capabilities = "CAPABILITY_IAM"

[prod-us-west-2.deploy.params]
stack_name = "xxx-prod"
s3_bucket = "sam-artifacts-xxx-us-east-1"
region = "us-west-2"
fail_on_empty_changeset = false
capabilities = "CAPABILITY_IAM"

You'll notice about that I'm repeating s3_bucket, fail_on_empty_changeset, capabilities in each table.

What I'd like instead is to leverage the existing semantics of global but in the env context

version = 1

[global.deploy.params]
s3_bucket = "sam-artifacts-xxx-us-east-1"
fail_on_empty_changeset = false
capabilities = "CAPABILITY_IAM"

[dev-us-east-1.deploy.params]
stack_name = "xxx-dev"
region = "us-east-1"

[prod-us-east-1.deploy.params]
stack_name = "xxx-prod"
region = "us-east-1"

[dev-us-west-2.deploy.params]
stack_name = "xxx-dev"
region = "us-west-2"

[prod-us-west-2.deploy.params]
stack_name = "xxx-prod"
region = "us-west-2"

Notice how there is no repeating values that are the same but don't change across envs making it easier to add new deployment envs and fewer places to change should the common parameters change

I believe this would be a simple addition here in addition to documentation and would be leveraging existing semantics. global is an alias for all command contexts in the command context position and sports overrides for specific command context.

global in this proposal can mean all envs in the env position and support overrides when a specific config env is defined.

This also harmonizes with the idea of global in templates themselves, a top level set of defaults

Things to consider:

1. Will this require any updates to the SAM Spec I don't believe so.

Additional Details

Thank you for making sam cli the great product that it is today. This change would make my life and hopefully the lives of others with more than one deployment target even better.

[jfuss]

@softprops Thanks for the issue and request. I can see a lot of benefits here and general life improvement for specific use-cases. I wonder if there are other ways we can surface this? Maybe some of our modeling in the .toml file means this is the only way to do it but worth the thought none the less.

Thank you for making sam cli the great product that it is today. This change would make my life and hopefully the lives of others with more than one deployment target even better.

Appreciate the kind words. Will make sure this gets back to the team :)

[softprops]

Thanks for getting back. After looking through how this works today it seems like it would be straight forward to introduce around here

The only drawback I can see of using global in the env position is that it could be a breaking change for users that happened to use an env named "global"

The benefits seem out way the cons so long as the change is well communicated

[softprops]

If y’all are into the idea I could take a first pass at a pr. I wanted to get a temperature test first before doing any work.

[brysontyrrell]

I am very into the idea. I came to GitHub to open this very issue and it's documented just as I was thinking. 👍

[galambborong]

Would be really good to know if anything came of this? As a feature, it's exactly what we're looking for! 😄

[softprops]

I may be coming back to some multi region work that would really benefit from the configuration drying technique. I think I know what and where to make the change but before I do I want to get a sense for how open y’all are open to change.

[dangeReis]

Was just looking into this and chatgtp and github copilot already think that the default environment is actually, you know, default and that other config-env would inherit from it. Sadly that does't seem to be the case.

Can we actually implement some inheritance here where we can have a common section that other environments can inherit from?