Add GitLab account factory setup docs

docs/2.0/docs/accountfactory/installation/index.md

@@ -6,16 +6,14 @@ Account Factory is automatically integrated into [new Pipelines root repositorie
 
 By default, Account Factory includes the following components:
 
-- An HTML form for generating workflow inputs: `.github/workflows/account-factory-inputs.html`
-
-- A workflow for generating new requests: `.github/workflows/account-factory.yml`
-
 - A root directory for tracking account requests: `_new-account-requests`
 
+- A mechanism for generating new account request files: `_new-account-requests/account-<AccountName>.yml`
+
 - A YAML file for tracking account names and IDs: `accounts.yml`
 
 For detailed instructions on using these components, refer to the [Vending a New AWS Account Guide](/2.0/docs/accountfactory/guides/vend-aws-account).
 
 ## Configuring account factory
 
-Account Factory is fully operational for vending new accounts without requiring any configuration changes. However, a [comprehensive reference for all configuration options is available here](/2.0/reference/accountfactory/configurations), allowing you to customize values and templates for generating Infrastructure as Code (IaC) for new accounts.
+Account Factory is fully operational for vending new accounts without requiring any configuration changes. However, a [comprehensive reference for all configuration options is available here](/2.0/reference/accountfactory/configurations-as-code), allowing you to customize values and templates for generating Infrastructure as Code (IaC) for new accounts.

docs/2.0/docs/overview/getting-started/index.md

@@ -22,12 +22,12 @@ Set up authentication for Pipelines to enable secure automation of infrastructur
 ### Step 4: Create new Pipelines repositories
 
 - [New GitHub repository](/2.0/docs/pipelines/installation/addingnewrepo)
-- [New GitLab repository](/2.0/docs/pipelines/installation/addingnewgitlabrepo)
+- [New GitLab repository](/2.0/docs/pipelines/installation/addinggitlabrepo)
 
 Alternatively, you can add Pipelines to an existing repository:
 
 - [Existing GitHub repository](/2.0/docs/pipelines/installation/addingexistingrepo)
-- [Existing GitLab repository](/2.0/docs/pipelines/installation/addinggitlabrepo)
+- [Existing GitLab repository](/2.0/docs/pipelines/installation/addingexistinggitlabrepo)
 
 <PersistentCheckbox id="install-df-4" label="Pipelines Repositories Ready" />
 

docs/2.0/docs/pipelines/architecture/ci-workflows.md

@@ -5,8 +5,8 @@ Pipelines integrates with your repositories through GitHub/GitLab Workflows, lev
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-<Tabs>
-<TabItem value="GitHub" label="GitHub">
+<Tabs groupId="platform" queryString="platform-ci-workflows">
+<TabItem value="github" label="GitHub">
 
 ```yml
 jobs:
@@ -15,7 +15,7 @@ jobs:
 ```
 
 </TabItem>
-<TabItem value="GitLab" label="GitLab">
+<TabItem value="gitlab" label="GitLab">
 
 ```yml
 include:
@@ -38,8 +38,8 @@ If you [fork the Gruntwork Workflows](https://docs.gruntwork.io/2.0/docs/pipelin
 
 ## Workflow dependencies
 
-<Tabs>
-<TabItem value="GitHub" label="GitHub">
+<Tabs groupId="platform" queryString="platform-ci-workflows">
+<TabItem value="github" label="GitHub">
 
 The `pipelines-workflows` repository includes the following reusable workflows:
 
@@ -70,7 +70,7 @@ If you are using [Gruntwork Account Factory](/2.0/docs/accountfactory/concepts/)
 - `pipelines.yml` - Uses `pipelines.yml`.
 
 </TabItem>
-<TabItem value="GitLab" label="GitLab">
+<TabItem value="gitlab" label="GitLab">
 
 Your `.gitlab-ci.yml` file will include the following workflow:
 

docs/2.0/docs/pipelines/concepts/cloud-auth/aws.mdx

@@ -1,7 +1,7 @@
 # Authenticating to AWS
 
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
+import Tabs from "@theme/Tabs"
+import TabItem from "@theme/TabItem"
 
 Pipelines automatically determines which AWS account(s) to authenticate with, and how to authenticate with them, based on the infrastructure changes proposed in your pull request.
 
@@ -15,7 +15,7 @@ When creating a new AWS account, it is necessary to update the AWS OIDC configur
 
 ## How Pipelines knows what AWS principals to authenticate as
 
-<Tabs>
+<Tabs groupId="config-type" queryString="config-type">
 <TabItem value="hcl" label="HCL">
 
 For HCL configurations, account mappings are defined using environments specified in HCL configuration files in the `.gruntwork` directory (you are using these if you see `.hcl` files in your `.gruntwork` directory).
@@ -177,7 +177,7 @@ Critically, the issuer is a URL that is both specified inside the token, and is
 
 Typically the issuer is the hostname of the CI/CD platform, such as `https://gitlab.com`, and thus oidc configuration (and public keys) can be fetched from the publicly available route, `https://gitlab.com/.well-known/openid-configuration` etc.
 
-If, however, your CI/CD platform is hosted privately, you will need to host the public key and OIDC configuration in a publicly accessible location, such as an S3 bucket, and update the issuer in your CI/CD configuration to point to that location.  The diagrams below illustrate both approaches - fetching the keys directly from your CI/CD platform via a public route, or fetching the keys from a public S3 bucket.
+If, however, your CI/CD platform is hosted privately, you will need to host the public key and OIDC configuration in a publicly accessible location, such as an S3 bucket, and update the issuer in your CI/CD configuration to point to that location. The diagrams below illustrate both approaches - fetching the keys directly from your CI/CD platform via a public route, or fetching the keys from a public S3 bucket.
 
 ### Publicly Available CI/CD Platforms
 
@@ -200,7 +200,7 @@ sequenceDiagram
 
 ### Non-Publicly Available CI/CD Platforms
 
-This diagram follows the [recommended approach](https://docs.gitlab.com/ci/cloud_services/aws/#configure-a-non-public-gitlab-instance) from GitLab for private CI/CD platform instances.  The guidance is to host the public key in a publicly accessible S3 bucket and update the issuer in the CI/CD configuration.
+This diagram follows the [recommended approach](https://docs.gitlab.com/ci/cloud_services/aws/#configure-a-non-public-gitlab-instance) from GitLab for private CI/CD platform instances. The guidance is to host the public key in a publicly accessible S3 bucket and update the issuer in the CI/CD configuration.
 
 A common alternative approach to re-hosting the public key and OIDC configuration is to update the application firewalls to specifically allow requests to the `.well-known/openid-configuration` endpoint and the JWKS endpoint from the AWS IdP.