12 Commits (c8e2be76d2572282d4bde28afdaeb03fdfba8764)

Author	SHA1	Message	Date
Laura Pacilio	31af9adc00	Make all sentences start with caps + additional tweak wording edits	5 years ago
Laura Pacilio	e7a8595e1d	Remove back ticks from apply command page	5 years ago
Laura Pacilio	ae2ff87598	Updates to page metadata for plan, apply, import, and destroy	5 years ago
Laura Pacilio	2233ef1782	Update description metadata for apply command	5 years ago
Alisdair McDiarmid	f9fc47c22e	website: Add documentation for machine readable UI ... Terraform 0.15.3 added support for a `-json` flag to the plan, apply, and refresh commands, which renders the Terraform UI output in a structured machine readable format. This commit adds documentation for this interface.	5 years ago
Nick Fagerlund	65f3ddec52	website: Make apply's usage of plan options harder to miss ... - I'm using distinct subheaders and smaller paragraphs to try and make the info about apply's two modes more skimmable. - I'm also adding a separate "Plan Options" subheader (and keeping the section tiny so it stays snugged up right next to the "Apply Options" one) to make it extra-clear that Hey, There's More Options, They're Over There.	5 years ago
Martin Atkins	42e0985839	command: use -lock=false consistently in -help output ... Previously the docs for this were rather confusing because they showed an option to turn _on_ state locking, even though it's on by default. Instead, we'll now show -lock=false in all cases and document it as _disabling_ the default locking. While working on this I also noticed that the equivalent docs on the website were differently inconsistent. I've not made them fully consistent here but at least moreso than they were before.	5 years ago
Martin Atkins	6bed3008a5	website: Reworking of the "terraform plan" docs, and related pages ... It's been a long time since we gave this page an overhaul, and with our ongoing efforts to make plan and apply incorporate all of the side-effects that might need to be done against a configuration it seems like a good time for some restructuring in that vein. The starting idea here is to formally split the many "terraform plan" options into a few different categories: - Planning modes - Planning options - Other options The planning modes and options are the subset that are also accepted by "terraform apply" when it's running in its default mode of generating a plan and then prompting for interactive approval of it. This then allows us to avoid duplicating all of that information on the "terraform apply" page, and thus allows us to spend more words discussing each of them. This set of docs is intended as a fresh start into which we'll be able to more surgically add in the information about -refresh-only and -replace=... once we have those implemented. Consequently there are some parts of this which may seem a little overwraught for what it's currently describing; that's a result of my having prepared this by just deleting the -refresh-only and -replace=... content from our initial docs draft and submitted the result, in anticipation of re-adding the parts I've deleted here in the very near future in other commits.	5 years ago
Sam Velie	5d04c4ea27	docs: correct spelling of normally (#28508)	5 years ago
Martin Atkins	6f35c2847b	command: Reorganize docs of the local backend's legacy CLI options ... We have these funny extra options that date back to before Terraform even had remote state, which we've preserved along the way by most recently incorporating them as special-case overrides for the local backend. The documentation we had for these has grown less accurate over time as the details have shifted, and was in many cases missing the requisite caveats that they are only for the local backend and that backend configuration is the modern, preferred way to deal with the use-cases they were intended for. We always have a bit of a tension with this sort of legacy option because we want to keep them documented just enough to be useful to someone who finds an existing script/etc using them and wants to know what they do, but not to take up so much space that they might distract users from finding the modern alternative they should consider instead. As a compromise in that vein here I've created a new section about these options under the local backend documentation, which then gives us the space to go into some detail about the various behaviors and interactions and also to discuss their history and our recommended alternatives. I then simplified all of the other mentions of these in command documentation to just link to or refer to the local backend documentation. My hope then is that folks who need to know what these do can still find the docs, but that information can be kept out of the direct path of new users so they can focus on learning about remote backends instead. This is certainly not the most ideal thing ever, but it seemed like the best compromise between the competing priorities I described above.	5 years ago
Nick Fagerlund	d1e8537b33	website: CLI: Update links to moved docs pages	5 years ago
Nick Fagerlund	a8332703c9	website: CLI: Move docs files to match new URLs	5 years ago