terraform

Commit Graph

Author	SHA1	Message	Date
Sarah French	371e625ea9	Update URLs from `www.terraform.io` to `developer.hashicorp.com` (#36792 ) * Update URLs from www.terraform.io to developer.hashicorp.com * More updates to URLs linking to documentation in documentation and user-facing warnings/errors * More updates to URLs linking to documentation, in docs, code, test fixtures * Replace www.terraform.io/community with link to Community Forum * Apply suggestions from code review Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com> --------- Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>	1 year ago
Tim Gates	dce91cafb4	docs: Fix a few typos There are small typos in: - docs/planning-behaviors.md - docs/resource-instance-change-lifecycle.md - website/README.md Fixes: - Should read `exhaustive` rather than `exhastive`. - Should read `representation` rather than `repesentation`. - Should read `preferably` rather than `preferrably`. - Should read `absence` rather than `absense`.	4 years ago
Martin Atkins	e00f0804ef	development docs: Planning Behaviors For a while now we've had information equivalent to this in various internal documents that we've referred to when designing features such as config-driven refactoring, the "replace" planning option, and so forth. However, so far we've not put that information in any sort of durable public place that we can easily find and refer to when having design discussions on GitHub and similar. This is therefore an attempt to capture a summary of the three main design patterns we've identified for planning-related behaviors, with a few motivating examples of each one, in the hope that this will be a good reference and some helpful inspiration for future design work. It's intentionally not totally comprehensive of all planning behaviors both because that would duplicate the end-user-oriented documentation and because it would be burdensome to keep updating this document each time we add anything new which might fit into these categories. However, we might add a later feature to this document if it illustrates a new take or different perspective on one of these patterns.	4 years ago

Author

SHA1

Message

Date

Sarah French

371e625ea9

Update URLs from `www.terraform.io` to `developer.hashicorp.com` (#36792 )

* Update URLs from www.terraform.io to developer.hashicorp.com

* More updates to URLs linking to documentation in documentation and user-facing warnings/errors

* More updates to URLs linking to documentation, in docs, code, test fixtures

* Replace www.terraform.io/community with link to Community Forum

* Apply suggestions from code review

Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>

---------

Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>

Tim Gates

dce91cafb4

docs: Fix a few typos

There are small typos in:
- docs/planning-behaviors.md
- docs/resource-instance-change-lifecycle.md
- website/README.md

Fixes:
- Should read `exhaustive` rather than `exhastive`.
- Should read `representation` rather than `repesentation`.
- Should read `preferably` rather than `preferrably`.
- Should read `absence` rather than `absense`.

Martin Atkins

e00f0804ef

development docs: Planning Behaviors

For a while now we've had information equivalent to this in various
internal documents that we've referred to when designing features such as
config-driven refactoring, the "replace" planning option, and so forth.

However, so far we've not put that information in any sort of durable
public place that we can easily find and refer to when having design
discussions on GitHub and similar.

This is therefore an attempt to capture a summary of the three main design
patterns we've identified for planning-related behaviors, with a few
motivating examples of each one, in the hope that this will be a good
reference and some helpful inspiration for future design work.

It's intentionally not totally comprehensive of all planning behaviors
both because that would duplicate the end-user-oriented documentation and
because it would be burdensome to keep updating this document each time we
add anything new which might fit into these categories. However, we might
add a later feature to this document if it illustrates a new take or
different perspective on one of these patterns.

3 Commits (stacks-variable-validations)