Modernize docs #787
Draft
Modernize docs #787
+376
−356
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
adamconnelly
reviewed
May 9, 2025
|
|
||
| If you're new to Spacelift, please spend some time browsing through the articles in the same order as they appear in the menu - start with the main concepts and follow with integrations. If you're more advanced, you can navigate directly to the article you need, or use the search feature to find a specific piece of information. If you still have questions, feel free to [reach out to us.](https://spacelift.io/contact){: rel="nofollow"} | ||
| - **State management**: Unlike application code, infrastructure changes rely on state files that track what's currently deployed |
There was a problem hiding this comment.
This is a super nit, so feel free to leave it as is, but I guess certain tools like CloudFormation don't use state files.
|
|
||
| Yes, you don't hear many of those stories. Most mistakes happen to well-meaning people. But in the world of infrastructure, even the tiniest of mistakes can cause major outages - like that typo we once made in our DNS config. That's why Spacelift adds an extra layer of [policy](concepts/policy/README.md) that allows you to control - separately from your infrastructure project! - [what code can be executed](concepts/policy/run-initialization-policy.md), [what changes can be made](concepts/policy/terraform-plan-policy.md), [when and by whom](concepts/policy/stack-access-policy.md). This isn't only useful to protect yourself from the baddies, but allows you to implement an [automated code review pipeline](concepts/policy/terraform-plan-policy.md#automated-code-review). | ||
| If you're ready to try Spacelift, [sign up for a free trial](https://spacelift.io/free-trial) or [contact our team](https://spacelift.io/contact) for a personalized demo. |
There was a problem hiding this comment.
Do you think it's worth mentioning the US region, or would we prefer people asked first?
| @@ -122,14 +122,14 @@ inputs: | |||
| type: secret | |||
| # secret means the input will be masked in the UI | |||
| - id: tf_version | |||
| name: Terraform version of the stack | |||
| name: OpenTofu/Terraform version of the stack | |||
There was a problem hiding this comment.
I think you can just change all the OpenTofu/Terraform updates in this example to OpenTofu. The reason is that this Blueprint example is explicitly creating an OpenTofu stack and not Terraform, so OpenTofu/Terraform is actually misleading here.
| @@ -113,7 +113,7 @@ The runner image is the Docker image used to run your workloads. By making it a | |||
| !!! info | |||
| Defaults to the **latest known supported Terraform version.** | |||
|
|
|||
| This setting is only valid on Terraform stacks and specifies the Terraform version that the run will use. The main use case is testing a newer version of Terraform before you use it to change the state since the way back is very hard. This version can only be equal to or higher than the one already used to apply state changes. For more details on Terraform version management, please refer to its [dedicated help section](../../../vendors/terraform/version-management.md). | |||
| This setting is only valid on Terraform stacks and specifies the binary version that the run will use. The main use case is testing a newer version of the binary before you use it to change the state since the way back is very hard. This version can only be equal to or higher than the one already used to apply state changes. For more details on OpenTofu/Terraform version management, please refer to its [dedicated help section](../../../vendors/terraform/version-management.md). | |||
There was a problem hiding this comment.
Suggested change
| This setting is only valid on Terraform stacks and specifies the binary version that the run will use. The main use case is testing a newer version of the binary before you use it to change the state since the way back is very hard. This version can only be equal to or higher than the one already used to apply state changes. For more details on OpenTofu/Terraform version management, please refer to its [dedicated help section](../../../vendors/terraform/version-management.md). | |
| This setting is only valid on OpenTofu/Terraform stacks and specifies the binary version that the run will use. The main use case is testing a newer version of the binary before you use it to change the state since the way back is very hard. This version can only be equal to or higher than the one already used to apply state changes. For more details on OpenTofu/Terraform version management, please refer to its [dedicated help section](../../../vendors/terraform/version-management.md). |
| @@ -118,9 +118,9 @@ There are two main use cases for run initialization policies - [protecting your | |||
|
|
|||
| ### Protect your stack from unwanted changes | |||
|
|
|||
| While specialized, Spacelift is still a CI/CD platform and thus allows running custom code before Terraform initialization phase using [`before_init`](../configuration/runtime-configuration/README.md#before_init-scripts)scripts. This is a very powerful feature, but as always, with great power comes great responsibility. Since those scripts get full access to your Terraform environment, how hard is it to create a commit on a feature branch that would run [`terraform destroy -auto-approve`](https://www.terraform.io/docs/commands/destroy.html){: rel="nofollow"}? Sure, all Spacelift runs are tracked and this prank will sooner or later be tracked down to the individual who ran it, but at that point do you still have a business? | |||
| While specialized, Spacelift is still a CI/CD platform and thus allows running custom code before OpenTofu/Terraform initialization phase using [`before_init`](../configuration/runtime-configuration/README.md#before_init-scripts) scripts. This is a very powerful feature, but as always, with great power comes great responsibility. Since those scripts get full access to your OpenTofu/Terraform environment, how hard is it to create a commit on a feature branch that would run [`tofu/terraform destroy -auto-approve`](https://opentofu.org/docs/cli/commands/destroy/){: rel="nofollow"}? Sure, all Spacelift runs are tracked and this prank will sooner or later be tracked down to the individual who ran it, but at that point do you still have a business? | |||
There was a problem hiding this comment.
Just a thought, maybe for actual command examples we can just use tofu. So instead of:
tofu/terraform destroy -auto-approve
We could just do:
tofu destroy -auto-approve
I just worry it's more confusing than helpful when showing commands to do this. If it was in a one page guide, I'd suggest just putting a callout at the top explaining that we're going to use tofu everywhere and that terraform is substitutable. But that's a little more tricky when it's across all the docs because although we could mention it somewhere people might not notice the note.
Personally I'd be tempted to just stick with tofu, but I get that there could be a concern that it makes it look like we don't support Terraform then.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of the change
Checklist
Please make sure that the proposed change checks all the boxes below before requesting a review:
mainbranch.If the proposed change is ready to be merged, please request a review from
@spacelift-io/solutions-engineering. Someone will review and merge the pull request.Spacelift employees should request reviews from the relevant engineers and are allowed to merge pull requests after they got at least one approval.
Thank you for your contribution! 🙇