aws-sam-cli: parameter-overrides on command line block samconfig.toml values

I just came across this. It would be great to have samcofig.toml parameter_overrides merged with the cli values.

In my samconfig.toml I used parameter_overrides to specify staging/prod environments:

version = 0.1
[staging]
[staging.deploy]
[staging.deploy.parameters]
stack_name = "boom-staging"
parameter_overrides = "Environment=\"staging\""

[prod]
[prod.deploy]
[prod.deploy.parameters]
stack_name = "boom-prod"
parameter_overrides = "Environment=\"prod\""

This makes it super easy to do a deploy script by just passing --config-env in ci. However I also pass in values to my stack that are generated at deploy time, so I pass these in via --parameter-overrides.

For example:

sam deploy --config-env staging --parameter-overrides LastUpdated=$(date '+%Y-%m-%d')

Since --parameter-overrides via the cli overrides the samconfig.toml, the settings defined there are basically useless and I have to type them over again.

So what should happen should be a merge, with the command-line taking preference.

Please don’t close this issue. The referenced issue (#2176) does not resolve the underlying problem of not being able to consistently override individual paramters.

Also ran into this, the documentation really needs correction here. My usecase is -

All default parameters are in config.toml and then pass a another parameter which will vary according the environment of deployment e.g. Env=dev or Env=prod

in that case, it would be really good if both params are merged

Hi @wchengru , I don’t believe the documentation clearly reflects the fact that a parameter-overrides command line argument completely replaces all of the values in the samconfig.toml parameter_overrides value. You linked to the .cn docs so maybe they’re different but what I reference in my initial ticket doesn’t seem that clear:

For the parameter_overrides entry, both the parameter values that you provide on the command line and entries in the configuration file take precedence over corresponding objects declared in the Parameters section of the template file.

Something like the following might be more clear:

For the parameter_overrides entry, the parameter values that you provide on the command line or the entries in the configuration file take precedence over corresponding objects declared in the Parameters section of the template file. If parameter-overrides are provided on the command line, none of the values in the the configuration file will be used.

btw, this need of different parameters on cli and config.toml can be solved by using --config-env or --config-file

more info here : https://github.com/aws/aws-sam-cli/pull/2176 https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-config.html

I think this issue can be closed.

My use case is only a subset of values require dynamic resolution which would require cli provided values but a majority are static values in which case the samconfig.toml file offers a great convenience as it really shortens my command line to deploy.

+1 for merging values parameter overrides specifically and let conflicting keys be resolved by preferring the command line overrides

I’m having the same issue, where I have a config-env for each environment, but part of the parameters are generated at runtime. The expected behaviour is merge and I was quite surprised to see it overwrites the config-env entirely. I think this is a really relevant feature and should be strongly considered.

I’d like to see sam overriding parameters from the configuration file only on parameter name clash Please increase the priority of the ticket @mousedownmike could you rework the issue title the way it would describe desired behavior?

Opting for now to go low tech

sed "s/{{RELEASE}}/$(RELEASE)/g" samconfig.template.toml > samconfig.toml 

Another use case from me: being able to inject or override a single parameter from some other data source, be it a secret store, some dynamic account info, a build tag, etc., without having to re-specify all parameters.

This merging behaviour could also apply to tags: for example, my customer has a big list of mandatory tags to apply to the environment. From a support perspective, if I could have all my deployments inject a build-ref tag that had the Git short ref or tag, I’d be able to more easily tell which version of a stack is deployed and debug issues.

For parameters: injection of a secret without hard-coding it into the repo would be nice (and yes, I’m aware of the implication of using it as a parameter, caveats around NoEcho, etc. etc. I’d just like the option…)

Using cat samconfig.template.toml | envsubst | tee samconfig.toml as a workaround for now. The samconfig.toml file is now listed in .gitignore.

I also ran into this issue, assuming that the command line arguments would override the values already defined in the configuration. The documentation is not clear that it will override everything. I also need to pass some values in at runtime, the rest are static.

Just ran into this issue. From the documentation I also assumed specific parameters I want to override on the command line are to be merged with parameters from the config file that don’t need to be changed. Some effort to resolve this issue would be greatly appreciated.

@qingchm, I don’t think my use case would be a strong driver for implementing this functionality but here are the basic bullet points.

• My samconfig.toml contains parameter_override values that cover 90% of my local test cases.
• To avoid excessive resource consumption when testing one function, I want to change one parameter.
• As we’ve seen overriding that one parameter on the command line isn’t possible.

I probably don’t understand TOML enough but I thought I could create some type of inheritance in my configuration but that doesn’t seem possible.

I ended up creating a separate TOML environment for this one case. Unfortunately all the other overrides have to be duplicated and the TOML syntax for them isn’t great… but it IS just a copy paste/update so it’s definitely survivable.