chore: use tab group ids (#2672)

Author: ZachGoldberg

docs/2.0/docs/pipelines/architecture/security-controls.md

@@ -13,7 +13,7 @@ By default, the only repository/group required to interact with infrastructure u
 import Tabs from "@theme/Tabs"
 import TabItem from "@theme/TabItem"
 
-<Tabs>
+<Tabs groupId="platform">
 <TabItem value="github" label="GitHub" default>
 
 - The AWS IAM role assumed via OIDC when pull requests are opened or updated has a trust policy that restricts access to the repository itself and provides read-only permissions
@@ -45,7 +45,7 @@ Unlike the infrastructure-live-root repository, this repository focuses on manag
 
 ## Token Strategy
 
-<Tabs>
+<Tabs groupId="platform">
 <TabItem value="github" label="GitHub" default>
 
 ### GitHub App Installation Strategy (Recommended)
@@ -83,7 +83,7 @@ Pipelines provisions an OpenID Connect identity provider in AWS IAM for each acc
 
 For more details, see the [official AWS documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html). Below is an example of a trust policy used by Pipelines.
 
-<Tabs>
+<Tabs groupId="platform">
 <TabItem value="github" label="GitHub" default>
 
 ```json

docs/2.0/docs/pipelines/guides/extending-pipelines.md

@@ -9,7 +9,7 @@ Extending Gruntwork Pipelines requires managing code across three distinct repos
 import Tabs from "@theme/Tabs"
 import TabItem from "@theme/TabItem"
 
-<Tabs>
+<Tabs groupId="platform">
 <TabItem value="github" label="GitHub" default>
 
 The repositories are:
@@ -36,7 +36,7 @@ This structure ensures that customers rarely need to modify Gruntwork-managed co
 
 <img alt="Diagram of Gruntwork Pipelines Repositories" className="img_node_modules-@docusaurus-theme-classic-lib-theme-MDXComponents-Img-styles-module medium-zoom-image" src="/img/pipelines/pipelines_customization_code_locations.svg" />
 
-<Tabs>
+<Tabs groupId="platform">
 <TabItem value="github" label="GitHub" default>
 
 Gruntwork Pipelines for GitHub is implemented as a [Reusable Workflow](https://docs.github.com/en/actions/using-workflows/reusing-workflows). This allows you to reference a specific pinned version in your `.github/workflows/pipelines.yml` file without hosting the workflow code yourself.
@@ -73,7 +73,7 @@ The recommended approach for customizing `pipelines-workflows` is to inject [cus
 
 #### Procedure
 
-<Tabs>
+<Tabs groupId="platform">
 <TabItem value="github" label="GitHub" default>
 
 This step-by-step guide outlines best practices for implementing custom actions:
@@ -123,7 +123,7 @@ Contact Gruntwork support for assistance setting up custom actions for Gruntwork
 
 #### Background / Explanation
 
-<Tabs>
+<Tabs groupId="platform">
 <TabItem value="github" label="GitHub" default>
 
 The `pipelines-root.yml` file includes several sample custom actions by default. Below is an example of the pre-provision new account custom hook:

docs/2.0/docs/pipelines/guides/managing-secrets.md

@@ -7,7 +7,7 @@ Continuous Integration systems often require access to sensitive resources, whic
 import Tabs from "@theme/Tabs"
 import TabItem from "@theme/TabItem"
 
-<Tabs>
+<Tabs groupId="platform">
 <TabItem value="github" label="GitHub" default>
 
 To interact with the GitHub API, Pipelines uses either a GitHub App or Machine User [Personal Access Tokens (PATs)](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens), depending on your installation method. For information on creating and managing these tokens, see the [Machine Users documentation](/2.0/docs/pipelines/installation/viamachineusers).
@@ -27,7 +27,7 @@ Pipelines requires authentication with AWS but avoids long-lived credentials by
 The role assumption process operates as follows:
 
 
-<Tabs>
+<Tabs groupId="platform">
 <TabItem value="github" label="GitHub" default>
 
 ```mermaid
@@ -176,7 +176,7 @@ terraform {
 
 When configuring providers and Pipelines, it's important to store secrets in a secure and accessible location. Several options are available for managing secrets, each with its advantages and trade-offs.
 
-<Tabs>
+<Tabs groupId="platform">
 <TabItem value="github" label="GitHub" default>
 
 #### GitHub Secrets

docs/2.0/docs/pipelines/guides/running-plan-apply.md

@@ -5,7 +5,7 @@ Pipelines automatically detects infrastructure changes in your committed IaC and
 import Tabs from "@theme/Tabs"
 import TabItem from "@theme/TabItem"
 
-<Tabs>
+<Tabs groupId="platform">
 <TabItem value="github" label="GitHub" default>
 
 The preferred workflow when working with Pipelines involves creating a new Pull Request with the desired changes, then reviewing the Terragrunt Plan output to ensure the infrastructure changes align with expectations. It is advisable to enforce [Branch Protection](/2.0/docs/pipelines/installation/branch-protection/#recommended-settings), particularly the [Require branches to be up to date](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) status check. This ensures the PR cannot be merged if the Plan is outdated.
@@ -32,7 +32,7 @@ Pipelines will add a comment to the merged merge request/pull request containing
 
 ## Skipping Pipelines plan/apply
 
-<Tabs>
+<Tabs groupId="platform">
 <TabItem value="github" label="GitHub" default>
 
 In certain scenarios, it may be necessary to skip Pipelines for specific commits. To do this, include one of the [workflow skip messages](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/skipping-workflow-runs), such as `[no ci]`, in the commit message.

docs/2.0/docs/pipelines/guides/updating-pipelines.md

@@ -5,7 +5,7 @@ Keeping Gruntwork Pipelines updated is straightforward. Regular updates are rele
 import Tabs from "@theme/Tabs"
 import TabItem from "@theme/TabItem"
 
-<Tabs>
+<Tabs groupId="platform">
 <TabItem value="github" label="GitHub" default>
 
 Regular updates are released for the Pipelines CLI, associated GitHub Actions Workflows, and custom GitHub Actions. To apply the latest updates across these components, modify the `pipelines.yml` file located in the `.github/workflows` directory of any repository integrated with Gruntwork Pipelines. Update the file to reference the latest version of the Pipelines GitHub Actions Workflow:

docs/2.0/docs/pipelines/tutorials/deploying-your-first-infrastructure-change.md

@@ -64,7 +64,7 @@ This section covers creating a resource in your AWS account using Pipelines and
 
 ### Planning the changes
 
-<Tabs>
+<Tabs groupId="platform">
 <TabItem value="github" label="GitHub" default>
 
 1. Create a new branch for your changes.
@@ -98,7 +98,7 @@ Click the *View Pipeline Logs* link to see the complete output of the Gruntwork
 
 ### Applying the changes
 
-<Tabs>
+<Tabs groupId="platform">
 <TabItem value="github" label="GitHub" default>
 
 If you are satisfied with the `terragrunt plan` output, proceed to merge the PR to create the S3 bucket.

docs/2.0/docs/pipelines/tutorials/destroying-infrastructure.md

@@ -37,7 +37,7 @@ This section explains how to destroy AWS resources using Pipelines and GitOps wo
 
 ### Planning the destruction
 
-<Tabs>
+<Tabs groupId="platform">
 <TabItem value="github" label="GitHub" default>
 
 Create a Pull Request (PR) for the branch you just pushed, targeting `main` (the default branch in your repository).