IntenseWebs/opentofu
3
0
Fork 0
mirror of https://github.com/opentofu/opentofu.git synced 2025-02-25 18:45:20 -06:00
Code Issues Packages Projects Releases Wiki Activity

Adds TACOS page to docs and links to it from all mentionds of TACOS (#1836)

Browse Source 
Signed-off-by: Andrew Hayes <andrew.hayes@harness.io>
This commit is contained in:
Andrew Hayes 2024-07-23 09:55:58 +01:00 committed by GitHub
parent faf9f6aedc
commit 520165c089
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
16 changed files with 47 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
website/docs/cli/auth/index.mdx
View File

@ -6,18 +6,18 @@ description: >-
# CLI Authentication
TACOS (TF Automation and Collaboration Software) are platforms that perform as part of their
[TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software) are platforms that perform as part of their
offering OpenTofu runs to provision infrastructure, offering a collaboration-focused
environment that makes it easier for teams to use OpenTofu together.
OpenTofu CLI integrates with TACOS in several ways — it can be a
front-end for CLI-driven runs, and can also use some TACOS as a state backend, a private module
OpenTofu CLI integrates with [TACOS](../../intro/tacos.mdx) in several ways — it can be a
front-end for CLI-driven runs, and can also use some [TACOS](../../intro/tacos.mdx) as a state backend, a private module
registry, or a private provider registry. All of these integrations require you to authenticate OpenTofu CLI
with your TACOS account.
with your [TACOS](../../intro/tacos.mdx) account.
The best way to handle CLI authentication is with the `login` and `logout`
commands, which help automate the process of getting an API token for your
TACOS user account.
[TACOS](../../intro/tacos.mdx) user account.
For details, see:

2
website/docs/cli/index.mdx
View File

@ -11,7 +11,7 @@ description: >-
This is the documentation for OpenTofu CLI. It is relevant to anyone working
with OpenTofu's CLI-based workflows; this includes people who use OpenTofu CLI
by itself, as well as those who use OpenTofu CLI in conjunction with
TACOS (TF Automation and Collaboration Software).
[TACOS](../intro/tacos.mdx) (TF Automation and Collaboration Software).
Notably, this documentation does not cover the syntax and usage of the OpenTofu
language. For that, see the

2
website/docs/intro/core-workflow.mdx
View File

@ -217,5 +217,5 @@ There are many different ways to use OpenTofu: as an individual user, a single
team, or an entire organization at scale. Choosing the best approach for the
density of collaboration needed will provide the most return on your investment
in the core OpenTofu workflow. For organizations using OpenTofu at scale,
TACOS (TF Automation and Collaboration Software) introduces new layers that build on this core workflow to
[TACOS](../intro/tacos.mdx) (TF Automation and Collaboration Software) introduces new layers that build on this core workflow to
solve problems unique to teams and organizations.

17
website/docs/intro/tacos.mdx Normal file
View File

@ -0,0 +1,17 @@
---
sidebar_position: 7
sidebar_label: What are TACOS?
description: |-
Learn all about TACOS.
---
# What are TACOS?
TF Automation and Collaboration Software (TACOS) are platforms which allow teams to manage and orchestrate OpenTofu execution. They offer a wide variety of services to provide a streamlined and collaborative experience.
# What are some examples?
There are a variety of platforms which offer OpenTofu support, both Open Source and Commercial. Many of these organizations support OpenTofu directly and can be found on our [supporters](../../../supporters) page.

2
website/docs/language/checks/index.mdx
View File

@ -68,7 +68,7 @@ Check blocks do not currently support [meta-arguments](../../language/resources/
## Continuous validation in TACOS (TF Automation and Collaboration Software)
TACOS (TF Automation and Collaboration Software) can automatically validate whether checks in a workspace’s configuration continue to pass after OpenTofu provisions new infrastructure.
[TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software) can automatically validate whether checks in a workspace’s configuration continue to pass after OpenTofu provisions new infrastructure.
## Choosing Checks or other Custom Conditions

2
website/docs/language/files/index.mdx
View File

@ -64,7 +64,7 @@ called by those modules, etc.).
- In OpenTofu CLI, the root module is the working directory where OpenTofu is
invoked. (You can use command line options to specify a root module outside
the working directory, but in practice this is rare.)
- In TACOS (TF Automation and Collaboration Software), the root module for a workspace
- In [TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software), the root module for a workspace
defaults to the top level of the configuration directory (supplied via version
control repository or direct upload), but the workspace settings can specify a
subdirectory to use instead.

2
website/docs/language/index.mdx
View File

@ -8,7 +8,7 @@ description: >-
# OpenTofu Language Documentation
This is the documentation for OpenTofu's configuration language. It is relevant
to users of [OpenTofu CLI](../cli/index.mdx), and TACOS (TF Automation and Collaboration Software).
to users of [OpenTofu CLI](../cli/index.mdx), and [TACOS](../intro/tacos.mdx) (TF Automation and Collaboration Software).
OpenTofu's language is its primary user interface. Configuration files you write in OpenTofu
language tell OpenTofu what plugins to install, what infrastructure to create,
and what data to fetch. OpenTofu language also lets you define dependencies

2
website/docs/language/modules/index.mdx
View File

@ -41,7 +41,7 @@ download them automatically if you specify the appropriate source and version in
a module call block.
Also, members of your organization might produce modules specifically crafted
for your own infrastructure needs. TACOS (TF Automation and Collaboration Software) include a private
for your own infrastructure needs. [TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software) include a private
module registry for sharing modules internally within your organization.
## Using Modules

4
website/docs/language/modules/sources.mdx
View File

@ -95,7 +95,7 @@ community.
You can also use a
[private registry](../../internals/module-registry-protocol.mdx), either
via TACOS (TF Automation and Collaboration Software), or by running a custom
via [TACOS](../../../intro/tacos.mdx) (TF Automation and Collaboration Software), or by running a custom
service that implements
[the module registry protocol](../../internals/module-registry-protocol.mdx).
@ -135,7 +135,7 @@ You can learn more about the registry at the
To access modules from a private registry, you may need to configure an access
token [in the CLI config](../../cli/config/config-file.mdx#credentials). Use the
same hostname as used in the module source string. For a private registry
within TACOS (TF Automation and Collaboration Software), use the same authentication token as you would
within [TACOS](../../../intro/tacos.mdx) (TF Automation and Collaboration Software), use the same authentication token as you would
use with the API or command-line clients.
## GitHub

2
website/docs/language/modules/syntax.mdx
View File

@ -98,7 +98,7 @@ version that meets the constraint.
Version constraints are supported only for modules installed from a module
registry, such as the [Public OpenTofu Registry](https://registry.opentofu.org/)
or any TACOS (TF Automation and Collaboration Software) private modules registry.
or any [TACOS](../../../intro/tacos.mdx) (TF Automation and Collaboration Software) private modules registry.
Other module sources can provide their own versioning mechanisms within the
source string itself, or might not support versions at all. In particular,
modules sourced from local file paths do not support `version`; since

4
website/docs/language/providers/index.mdx
View File

@ -63,7 +63,7 @@ about it in your configuration. See the following pages for details:
## Provider Installation
- TACOS (TF Automation and Collaboration Software) install providers as part of every run.
- [TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software) install providers as part of every run.
- OpenTofu CLI finds and installs providers when
[initializing a working directory](../../cli/init/index.mdx). It can
@ -79,7 +79,7 @@ To ensure OpenTofu always installs the same provider versions for a given
configuration, you can use OpenTofu CLI to create a
[dependency lock file](../../language/files/dependency-lock.mdx)
and commit it to version control along with your configuration. If a lock file
is present, OpenTofu CLI, and TACOS (TF Automation and Collaboration Software) will all obey it when
is present, OpenTofu CLI, and [TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software) will all obey it when
installing providers.
## How to Find Providers

2
website/docs/language/providers/requirements.mdx
View File

@ -203,7 +203,7 @@ To ensure OpenTofu always installs the same provider versions for a given
configuration, you can use OpenTofu CLI to create a
[dependency lock file](../../language/files/dependency-lock.mdx)
and commit it to version control along with your configuration. If a lock file
is present, OpenTofu CLI, and TACOS (TF Automation and Collaboration Software) will all obey it when
is present, OpenTofu CLI, and [TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software) will all obey it when
installing providers.
### Best Practices for Provider Versions

4
website/docs/language/settings/backends/configuration.mdx
View File

@ -8,7 +8,7 @@ description: >-
A backend defines where OpenTofu stores its [state](../../../language/state/index.mdx) data files.
OpenTofu uses persisted state data to keep track of the resources it manages. Most non-trivial OpenTofu configurations either integrate with TACOS (TF Automation and Collaboration Software) or use a backend to store state remotely. This lets multiple people access the state data and work together on that collection of infrastructure resources.
OpenTofu uses persisted state data to keep track of the resources it manages. Most non-trivial OpenTofu configurations either integrate with [TACOS](../../../intro/tacos.mdx) (TF Automation and Collaboration Software) or use a backend to store state remotely. This lets multiple people access the state data and work together on that collection of infrastructure resources.
This page describes how to configure a backend by adding the [`backend` block](#using-a-backend-block) to your configuration.
@ -20,7 +20,7 @@ Some of these backends act like plain remote disks for state files, while others
## Using a Backend Block
You do not need to configure a backend when using TACOS (TF Automation and Collaboration Software) because
You do not need to configure a backend when using [TACOS](../../../intro/tacos.mdx) (TF Automation and Collaboration Software) because
it automatically manages state in the workspaces associated with your configuration. If your configuration includes a [`cloud` block](../../../language/settings/tf-cloud.mdx), it cannot include a `backend` block.
To configure a backend, add a nested `backend` block within the top-level

14
website/docs/language/settings/backends/remote.mdx
View File

@ -11,16 +11,16 @@ description: >-
**We recommend using the [`cloud` built-in integration](../../../cli/cloud/settings.mdx)** instead of this backend. The `cloud` option includes an improved user experience and more features.
:::
The remote backend is unique among all other OpenTofu backends because it can both store state snapshots and execute CLI-driven run workflow operations for TF Automation and Collaboration Software (TACOS) backends. It used to be called an "enhanced" backend.
The remote backend is unique among all other OpenTofu backends because it can both store state snapshots and execute CLI-driven run workflow operations for TF Automation and Collaboration Software ([TACOS](../../../intro/tacos.mdx)) backends. It used to be called an "enhanced" backend.
If your TACOS provider enables full remote operations, you can execute commands such as `tofu plan` or `tofu apply` within the TACOS runtime environment, with log output streaming directly to your local terminal. Remote plans and applies use variable values from the associated remote workspace.
If your [TACOS](../../../intro/tacos.mdx) provider enables full remote operations, you can execute commands such as `tofu plan` or `tofu apply` within the [TACOS](../../../intro/tacos.mdx) runtime environment, with log output streaming directly to your local terminal. Remote plans and applies use variable values from the associated remote workspace.
You can also use TACOS with local operations, where only state is stored in the TACOS remote backend.
You can also use [TACOS](../../../intro/tacos.mdx) with local operations, where only state is stored in the [TACOS](../../../intro/tacos.mdx) remote backend.
## Command Support
:::note
Features implementation might vary between different TACOS.
Features implementation might vary between different [TACOS](../../../intro/tacos.mdx).
:::
The remote backend supports the following OpenTofu commands:
@ -66,7 +66,7 @@ setting both results in a configuration error.
If previous state is present when you run `tofu init` and the corresponding
remote workspaces are empty or absent, OpenTofu will create workspaces and
update the remote state accordingly. However, if your workspace requires variables or a specific version of OpenTofu for remote operations, we
recommend that you create your remote workspaces on TACOS before
recommend that you create your remote workspaces on [TACOS](../../../intro/tacos.mdx) before
running any remote operations against them.
### Workspace Names
@ -179,7 +179,7 @@ The following configuration options are supported:
only the default workspace can be used. This option conflicts with `prefix`.
- `prefix` - (Optional) A prefix used in the names of one or more remote
workspaces, all of which can be used with this configuration. The full
workspace names are used in TACOS, and the short names
workspace names are used in [TACOS](../../../intro/tacos.mdx), and the short names
(minus the prefix) are used on the command line for OpenTofu CLI workspaces.
If omitted, only the default workspace can be used. This option conflicts with `name`.
@ -212,7 +212,7 @@ the remote workspace accept the following option to modify that behavior:
## Excluding Files from Upload with .terraformignore
When executing a remote `plan` or `apply` in a CLI-driven run,
an archive of your configuration directory is uploaded to TACOS. You can define
an archive of your configuration directory is uploaded to [TACOS](../../../intro/tacos.mdx). You can define
paths to ignore from upload via a `.terraformignore` file at the root of your configuration directory. If this file is not present, the archive will exclude the following by default:
- `.git/` directories

2
website/docs/language/state/index.mdx
View File

@ -12,7 +12,7 @@ resources to your configuration, keep track of metadata, and to improve
performance for large infrastructures.
This state is stored by default in a local file named "terraform.tfstate",
but we recommend storing it in TACOS (TF Automation and Collaboration Software)
but we recommend storing it in [TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software)
to version, encrypt, and securely share it with your team.
OpenTofu uses state to determine which changes to make to your

6
website/docs/language/state/remote.mdx
View File

@ -14,11 +14,11 @@ OpenTofu at the same time.
With _remote_ state, OpenTofu writes the state data to a remote data store,
which can then be shared between all members of a team. OpenTofu supports
storing state in TACOS (TF Automation and Collaboration Software),
storing state in [TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software),
[HashiCorp Consul](https://www.consul.io/), Amazon S3, Azure Blob Storage, Google Cloud Storage, Alibaba Cloud OSS, and more.
Remote state is implemented by a [backend](../../language/settings/backends/configuration.mdx) or by
TACOS (TF Automation and Collaboration Software), both of which you can configure in your configuration's root module.
[TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software), both of which you can configure in your configuration's root module.
## Delegation and Teamwork
@ -54,7 +54,7 @@ For fully-featured remote backends, OpenTofu can also use
[state locking](../../language/state/locking.mdx) to prevent concurrent runs of
OpenTofu against the same state.
TACOS (TF Automation and Collaboration Software) is a commercial offering
[TACOS](../../intro/tacos.mdx) (TF Automation and Collaboration Software) is a commercial offering
that supports an even stronger locking concept that
can also detect attempts to create a new plan when an existing plan is already
awaiting approval, by queuing OpenTofu operations in a central location.