Aws-cli: Allow cloudformation deploy to accept a paramater file

[akashisama]

When running the cloudformation deploy command it would be useful to be able to pass the parameters in as a file (to the --parameter-override parameter), as can be done with create-stack and update-stack.

Also requested here: https://github.com/awslabs/serverless-application-model/issues/111

[cwgem]

Looking over the code it seems we'd just need something around here

https://github.com/aws/aws-cli/blob/develop/awscli/customizations/cloudformation/deploy.py#L178

that reads in a JSON file, maybe a quick sanity check, then passes it along to deploy().

[stealthycoin]

Marking as a feature request for cloudformation deploy.

@sanathkr thoughts?

[philipakash]

waiting for this feature 👍

[larryboymi]

I would also like the feature for package actions. Thanks! 👍

[dumrauf]

Passing a parameters file via something like --parameters as in the create-stack and update-stack CF commands (and ideally using the same file contents syntax) would make developing CF templates a tad easier for me. Would love to see that feature.

[anthonynovatsis]

+1 for this feature. Thanks!

[ASayre]

Good Morning!

We're closing this issue here on GitHub, as part of our migration to UserVoice for feature requests involving the AWS CLI.

This will let us get the most important features to you, by making it easier to search for and show support for the features you care the most about, without diluting the conversation with bug reports.

As a quick UserVoice primer (if not already familiar): after an idea is posted, people can vote on the ideas, and the product team will be responding directly to the most popular suggestions.

We’ve imported existing feature requests from GitHub - Search for this issue there!

And don't worry, this issue will still exist on GitHub for posterity's sake. As it’s a text-only import of the original post into UserVoice, we’ll still be keeping in mind the comments and discussion that already exist here on the GitHub issue.

GitHub will remain the channel for reporting bugs.

Once again, this issue can now be found by searching for the title on: https://aws.uservoice.com/forums/598381-aws-command-line-interface

-The AWS SDKs & Tools Team

This entry can specifically be found on UserVoice at: https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168409-allow-cloudformation-deploy-to-accept-a-paramater

[ghost]

+1 for this feature. Thanks!

[jamesls]

Based on community feedback, we have decided to return feature requests to GitHub issues.

[foobert]

In case anyone is looking for a workaround, you can try using jq, like so:
aws cloudformation deploy --parameter-overrides $(jq -r '.[] | [.ParameterKey, .ParameterValue] | join("=")' param.json) ...
Further escaping may be necessary based on your parameter values.

[holmesjr]

I'm going to +1 this feature too.

[mbailey]

I'm replacing jq with jp wherever possible. JMESPath is worth learning.

$ jp \
  --unquoted \
  --filename example-app-params-staging.json  \
  "join(' ', @[].join('=', [ParameterKey, ParameterValue])[])"
HostedZone=example.com KeyName=example-ap-southeast-2 TargetPort=8080 VpcStackName=vpc-example

[mixja]

Given AWS CodePipeline CloudFormation deployment action requires a specific template configuration file format, it would be good if you could also support this format as well.

[cervantek]

+1 for this. I understand wanting to keep "aws cloudformation deploy" simple, but this command already has individual command line flags for capabilities, tags, and parameters (like all other aws cloudformation commands), but you've made them function differently (only accepting list of string=string on the command line, rather than a JSON structure in a file). You should make all "aws cloudformation" commands work consistently (including use of cli-input-json like almost all aws CLI commands). if you wanted a simplification of the tags construct for "aws cloudformation deploy", you should introduce a different command line flag, like --tags-overrides or --parameters-overrides.

[emilbryggare]

👍 on the feature request, would be great if this was supported.

[pmartindev]

This would be a great feature to have! It would greatly simplify Idempotency when creating cf stacks with the cli 👍

[mnwk]

+1

[dan-lind]

+1

[ColdFire87]

+1

[pierreozoux]

@ColdFire87 @dan-lind @mnwk can you please just 👍 the first issue, and stop spamming whoever is subscribed to this issue? Each comment with 👍 is pinging 20 persons....
(Sorry for others, but we have to fight that...)

[ColdFire87]

@pierreozoux Sorry about that, I didn't mean to annoy people :)

[alexharv074]

What @cervantek said. I just want to add that I would hope that this ticket tracks implementing all of these options for consistency with create-stack:

          [--template-body <value>]
          [--template-url <value>]
          [--parameters <value>]
          [--capabilities <value>]
          [--tags <value>]

Many people like me will have legacy code that was written using create-stack and update-stack and they will want to rewrite it to use deploy. It shouldn't be this hard.

[olivier-schmitt-sonarsource]

+1 to --parameters supports JSON file.

[ElliottBabb]

Our team recently began generating cloudformation templates that were large enough to require an upload to an S3 bucket, so we are now making the transition from create-stack and update-stack to deploy...and are running into the same problem of migrating our parameters file to work with this new command. +1 for this feature

[anshul0915]

+1 for this feature

[lmunro]

+1

[MiMo42]

+1

[markusbecker]

+1

[benjammin12]

+1

[isobit]

@olivier-schmitt-sonarsource @anshul0915 @lmunro @MiMo42 @markusbecker @benjammin12 and others in the future, please just 👍 the parent issue instead of spamming those of us subscribed to the thread with comments if you just want to +1 the issue. Thanks.

[jeff1evesque]

👍

[awshumway]

another workaround for this is using an .ini file with a list of key=value parameter pairs, and deploy using:
aws cloudformation deploy --parameter-overrides $(cat parameters.ini)
the same can be done for tags.

[pablods90]

another workaround for this is using an .ini file with a list of key=value parameter pairs, and deploy using:
aws cloudformation deploy --parameter-overrides $(cat parameters.ini)
the same can be done for tags.

This approach is nice and works! Nevertheless, in order to keep consistency with all the other commands (that do support 'json' input), the advice is to keep the parameters in 'json' file format and specifically manipulate the file before using it as input for the 'deploy' command. This can be accomplished with the 'jq' command which is available for all the most common platforms.

The conversion can be easily achieved with:

cat parameters.json | jq -r '.[] | .ParameterKey + "=" + .ParameterValue'

Moreover, it can be converted on the fly and used directly as input for the deploy command:

aws cloudformation deploy --template-file ./sample-template.yaml --stack-name sample-stack --parameter-overrides $(cat parameters.json | jq -r '.[] | .ParameterKey + "=" + .ParameterValue')

Hope it helps!

[holmesjr]

Luckily this whole problem is completely obviated by CDK. I've moved on.

[danbo0001]

I have been trying to move to the deploy method from create-stack/update-stack and have been getting this plus other issues - I am surprised after 3 years it still does not have parity with those old methods.

I am getting problems using the workaround above for tags files where some tags have spaces in their values. I am sure this is resolvable, but my other issue is more fundamental - the output of this command is unstructured, so in order to obtain the changeset id I have to parse an unstructured text string. I consider this very dodgy (!) especially since the create-change-set method returns the id in json.

The link to the issue on uservoice in an earlier message on this thread is dead - does anyone know where this problem is being currently tracked or if it is even still being worked on?

[dzmitry-kankalovich]

Guys, please do consider implementing this feature. Using tricks with cat or passing params via SSM as a workaround - it is an unnecessary complication over a very basic functionality, and such functionality is supported by pretty much every other alternative to CFN.

[Ricapar]

I came across this thread while looking for a solution for passing parameters to create-stack and update-stack, but I'll give my 👍 here too, but adding onto the request that we have an option to pass a file that follows the JSON format that CodePipeline accepts for CloudFormation.

If you're a heavy user of CodePipeline for deploying CloudFormation, it's already customary to have your CloudFormation files in the CodePipeline format committed within your repositories.

This works great for when you're running a full CI/CD run via the pipeline, but it makes for very tedious local development. I have some scripts that can translate the CodePipeline JSON into the JSON that aws cloudformation create-stack and update-stack accept via --parameters file://params.json, and with some extra work probably can probably work in some of the hacks folks above have mentioned with jq and the like, but that just feels like a hack.

[danil-smirnov]

Please implement this!

[vinodfmi]

Please Implement this! Come on AWS, this has been open for almost 3 years.

[dzmitry-kankalovich]

Another thing that is extremely annoying and somewhat related to the topic is the inconsistency between formats for supplying CFN parameters via CLI.

I am a deploy user at the moment, and so far had been able to get away with it using inline parameters via tricks with cat - i.e. --parameter-overrides $(shell cat configs/${LNMS_ENV}.properties).

The problem arose when I decided to implement something similar to Terraform's plan by using CFN's Change Sets. Turns out aws cloudformation create-change-set is capable of parameters override, but it expects them to be shipped in a different than deploy format!

Per CLI documentation for deploy it is:

ParameterKey1=ParameterValue1

Per CLI documentation for create-stack, update-stack and create-change-set it is:

ParameterKey=string,ParameterValue=string

with also an option to supply JSON.

I really don't get why they're different, why deploy won't support the same JSON format, and what am I supposed to do - keep two essentially the same param files for every environment?

This honestly a really strange design - no consistency, and un-justifiable motivation to avoid usage of parameter files. Small (and it is arguable that they're small) things like this really affect productivity.

P.S. Didn't notice @pablods90 take on this, but only proves the point that people are keeping re-inventing a wheel due to the lack of basic functionality :(

[chris-bateman]

+1

[dzmitry-kankalovich]

The adventures of Captain Consistency continue.

While we can get away with the usage of cat to store configs for deploy in a format that is also compatible with update-stack:

[
    {
        "ParameterKey": "ParamEnv",
        "ParameterValue": "prod"
    }
]

The CodePipeline with Deploy:CloudFormation type of action uses another file format to pass to CFN:

{ 
  "Parameters": {
     "ParamEnv": "prod"
  }
}

No further comments... Really tired of hitting the same problem over and over and over again. This is bad.

[hauntingEcho]

we ended up just having one-line shell scripts to call aws cloudformation deploy maintained alongside the files for CodePipeline, rather than cat or jq shenanigans.

[danacon01]

i think this is one of those issues they are not going to fix, maybe coz their focus now is the cdk?

anyways i gave up waiting and trying to shoehorn deploy into doing what i thought it should do and ended up doing what i think most others have done - write my own "upsert" bash script using create and update stack cli commands. 100 lines long but at least it does the job now!

[YAMABASS80]

Hi, I really need this. I truly disappointed to see this situation, where people asking to make this for years but CloudFormation haven't provided yet. What kind of idea drive the team this is acceptable.....

[vz10]

Hey, we're really sorry that it took such a long time to get to this issue.

Could you please have a look at the description of the PR and let us know what do you think about such solution.

[bs-thomas]

Also, it seems like there is no easy way (at least on Windows Command Prompt CLI) to provide a multi-line parameter.

I'd hope with the implementation of this parameter file feature, it would save the multi-line parameter issue.

Thank you very much for the great work guys!

[vz10]

Hi, this PR was merged and released in AWS CLI v.2.0.39.

[bs-thomas]

@vz10 Thanks for the update.

Btw, do you happen to know if this implementation (via a parameter file) allows multi-line parameters? This was one of the things I couldn't get through in the Windows batch environment running AWS CLI.

Thanks for your assistance in advance!

[vz10]

@bs-thomas I didn't test it with multi-line parameters. But I believe if JSON format supports it, it will work fine.

It'd be great if you can try it out and give us a feedback.

Thank you.

[bs-thomas]

@vz10 Multi-line indeed is working. However, it looks very ugly with \n

Actually, it'd be cool if CLI can suport YAML format for the CLI parameter-overrides ;-)

[vz10]

@bs-thomas it looks like another feature request.

Just create it and it'll it be half the battle of making parameter-overrides understand YAML ;)

[bs-thomas]

@vz10 Sure, I'll do that right away.

Btw, I noticed something unpleasant about the JSON validator. It does not accept integer nor boolean values. So if I have them, it must be specified as a string, else I'll get this response:

[bs-thomas]

Tada!

[vz10]

@bs-thomas yeah, it's a bit weird but it's the same behavior that cloudformation create-stack expects - all values are strings and it parses them after and it doesn't have boolean parameter type