Enforce that we don't use relative links (#2218)

ZachGoldberg · web-flow · commit 57e183e86fc3 · 2024-11-22T11:27:38.000-08:00
* Enforce that we don't use relative links

* we can actually enforce this across all of docs

* Look for `../` as well, limit to 2.0 as our automated guides do use relative links sometimes

* link fix

* 2 more links

* more link fixes

* more links

* mooore links

* final links
diff --git a/.circleci/config.yml b/.circleci/config.yml
@@ -54,6 +54,11 @@ references:
       name: spellcheck
       command: yarn && yarn spellcheck
 
+  no_relative_links: &no_relative_links
+    run:
+      name: ensure_no_relative_links
+      command: yarn && yarn relative-link-check
+
   test_docs: &test_docs
     run:
       name: test
@@ -150,6 +155,7 @@ jobs:
       - checkout
       - *build_docs
       - *spellcheck_docs
+      - *no_relative_links
       - *test_docs
     # The resource_class feature allows configuring CPU and RAM resources for each job. Different resource classes are
     # available for different executors. https://circleci.com/docs/2.0/configuration-reference/#resourceclass
diff --git a/docs/2.0/docs/accountfactory/architecture/logging.md b/docs/2.0/docs/accountfactory/architecture/logging.md
@@ -34,7 +34,7 @@ Access to CloudTrail is controlled by AWS IAM policies that are assigned to indi
 Gruntwork recommends that only those with administrative access to an AWS account have access to view CloudTrail logs, as they contain a record of every single API operation that was performed in the account, which may expose the name or configuration of resources an individual user may otherwise not have access to.
 :::
 
-Further, the configuration of CloudTrail trails should be defined as code, with all changes reviewed in a pull request before being applied automatically by [Gruntwork Pipelines](../../pipelines/overview.md).
+Further, the configuration of CloudTrail trails should be defined as code, with all changes reviewed in a pull request before being applied automatically by [Gruntwork Pipelines](/2.0/docs/pipelines/concepts/overview).
 
 See [Identity-based policy examples for AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/security_iam_id-based-policy-examples.html) to learn more about granting access to CloudTrail.
 
diff --git a/docs/2.0/docs/library/concepts/overview.md b/docs/2.0/docs/library/concepts/overview.md
@@ -21,4 +21,3 @@ To learn more, refer to [Modules](/2.0/docs/library/concepts/modules)
 **Service modules** are opinionated combinations of "building block" modules described above. They are designed to be used "off the shelf" with no need to assemble a collection of “building block” modules on your own. They typically represent a full use case to solve a business problem on their own. For example, the `vpc` service module deploys a VPC, VPC Flow Logs, and Network ACLs. If you agree with the opinions embedded in a service module, they’re the fastest way to deploy production-grade infrastructure.
 
 To learn more, refer to [Service Modules](/2.0/docs/library/concepts/service-modules)
-
diff --git a/docs/2.0/docs/library/guides/integrate-tfc.md b/docs/2.0/docs/library/guides/integrate-tfc.md
@@ -95,7 +95,7 @@ data source](https://www.terraform.io/docs/providers/terraform/d/remote_state.ht
 another workspace. In this manner, you can link multiple workspaces together to
 build an end-to-end infrastructure.
 
-In our guide on [using Gruntwork modules](../tutorials/customizing-modules.md), we discuss the wrapper module
+In our guide on [using Gruntwork modules](/2.0/docs/library/tutorials/customizing-modules), we discuss the wrapper module
 pattern in which multiple Terraform modules are contained in a hierarchy of directories located under
 `infrastructure-modules/modules`. Using such a hierarchy, each workspace will use the same `infrastructure-modules` repository, but pointed at different subdirectories within the repository.
 
diff --git a/docs/2.0/docs/library/tutorials/creating-service-module.md b/docs/2.0/docs/library/tutorials/creating-service-module.md
@@ -28,7 +28,7 @@ touch gw_service_guide/serverless-api/outputs.tf
 
 ### Define the service
 
-Next, define the module blocks for the AWS Lambda function and HTTP API Gateway. For the Lambda, we will use the [Lambda function module](../../../../reference/modules/terraform-aws-lambda/lambda/), for the HTTP API Gateway we will use the [HTTP API Gateway module](../../../../reference/modules/terraform-aws-lambda/lambda-http-api-gateway/).
+Next, define the module blocks for the AWS Lambda function and HTTP API Gateway. For the Lambda, we will use the [Lambda function module](/reference/modules/terraform-aws-lambda/lambda/), for the HTTP API Gateway we will use the [HTTP API Gateway module](/reference/modules/terraform-aws-lambda/lambda-http-api-gateway/).
 
 To keep the configuration simple for this guide, we define a single route — `ANY /{proxy+}`. This tells the API Gateway to send any requests matching the path `/*` to the Lambda. This is an effective approach if you are using an API framework in the Lambda function code that can handle request routing. We will also set some defaults for the Lambda to not run in a VPC, have a maximum run time of 30 seconds, and 128MB of memory.
 
diff --git a/docs/2.0/docs/library/tutorials/module-defaults.md b/docs/2.0/docs/library/tutorials/module-defaults.md
@@ -2,7 +2,7 @@
 
 ## Defining module defaults
 
-Now that you have an understanding of [what module defaults are](../concepts/module-defaults.md), you can develop your own defaults module.
+Now that you have an understanding of [what module defaults are](/2.0/docs/library/concepts/module-defaults), you can develop your own defaults module.
 
 All of your defaults modules should be placed in a directory named `_module_defaults`. Beyond that, it is up to you as a developer to determine how to structure the code. Gruntwork recommends structuring your module defaults directory by creating directories for each resource category (e.g., storage, networking) then using a name for the Terragrunt file that represents the resource(s) it will create.
 
@@ -37,7 +37,7 @@ locals {
 
 Finally, you can define inputs. This is where the module defaults pattern really starts to demonstrate value by keeping your code DRY.
 
-In the example block below, we’ve set default values for the `vpc_name` and `num_nat_gateways` variables. A quick inspection of the [`vpc-app`](../../../../../reference/modules/terraform-aws-vpc/vpc-app/) module shows us that we’re only missing one additional required variable — `cidr_block`. This means that consumers of our defaults module only need to specify a value for one input variable, a 66% reduction! You could even expand this example to always use the same CIDR block, allowing consumers to override it should they require a different block.
+In the example block below, we’ve set default values for the `vpc_name` and `num_nat_gateways` variables. A quick inspection of the [`vpc-app`](/reference/modules/terraform-aws-vpc/vpc-app/) module shows us that we’re only missing one additional required variable — `cidr_block`. This means that consumers of our defaults module only need to specify a value for one input variable, a 66% reduction! You could even expand this example to always use the same CIDR block, allowing consumers to override it should they require a different block.
 
 
 ```hcl title=_module_defaults/networking/vpc-app.hcl
@@ -58,7 +58,7 @@ Now that you know how to develop an defaults module, let’s dive in to how you
 
 ### Infrastructure units
 
-An infrastructure unit is the Gruntwork term for the deployment of an infrastructure as code module in a single environment. For example, deploying the [`vpc-app`](../../../../reference/modules/terraform-aws-vpc/vpc-app/) module in your development AWS account is a single infrastructure unit.
+An infrastructure unit is the Gruntwork term for the deployment of an infrastructure as code module in a single environment. For example, deploying the [`vpc-app`](/reference/modules/terraform-aws-vpc/vpc-app/) module in your development AWS account is a single infrastructure unit.
 
 In this section, we’ll walk through the approach we employ at Gruntwork for leveraging defaults modules as infrastructure units. When you purchase a DevOps Foundation, the generated repository containing your infrastructure as code is automatically laid out to use this approach.
 
diff --git a/docs/2.0/docs/overview/concepts/infrastructure-live.md b/docs/2.0/docs/overview/concepts/infrastructure-live.md
@@ -77,4 +77,4 @@ For more details and the other options, see [Keep your Terragrunt Architecture D
 ### Module defaults
 
 
-Now that you have your accounts, environments, categories, resources, and state figured out, you may be wondering how you can increase code re-use across your `live` repository. Gruntwork recommends using the ["module defaults"](../../library/concepts/module-defaults.md) pattern to keep your Terragrunt architecture DRY.
+Now that you have your accounts, environments, categories, resources, and state figured out, you may be wondering how you can increase code re-use across your `live` repository. Gruntwork recommends using the ["module defaults"](/2.0/docs/library/concepts/module-defaults) pattern to keep your Terragrunt architecture DRY.
diff --git a/docs/2.0/docs/overview/concepts/labels-tags.md b/docs/2.0/docs/overview/concepts/labels-tags.md
@@ -31,7 +31,7 @@ As an example, if Acme Co was running an application named `coolapp` on AWS EC2
 
 ### Adding labels
 
-The simplest way to create a label is using a `locals` block and combining the recommended attributes into a single attribute. For example, if you were creating an AWS S3 bucket using a Gruntwork module you could set up the following locals block. If you are using the [module defaults pattern](../../library/concepts/module-defaults.md), placing the name logic in the default module will ensure that all consumers of the module will use the same naming scheme automatically by default.
+The simplest way to create a label is using a `locals` block and combining the recommended attributes into a single attribute. For example, if you were creating an AWS S3 bucket using a Gruntwork module you could set up the following locals block. If you are using the [module defaults pattern](/2.0/docs/library/concepts/module-defaults), placing the name logic in the default module will ensure that all consumers of the module will use the same naming scheme automatically by default.
 
 ```hcl
 terraform {
diff --git a/docs/2.0/docs/overview/iac-foundations/overview.md b/docs/2.0/docs/overview/iac-foundations/overview.md
@@ -11,7 +11,7 @@ The IaC Foundations component is focused on:
 - **IaC Modules.** No IaC modules are needed for this component.
 - **Tooling.** We recommend Terragrunt to effectively use Terraform/OpenTofu at scale.
 - **Setup.** We grant you access to a sophisticated git repo template that includes customization options and generates your repo code.
-- **Updates.** We publish ongoing updates to IaC foundational patterns and will write [patches](../../patcher/patcher.md) if applicable to adopt those changes.
+- **Updates.** We publish ongoing updates to IaC foundational patterns and will write [patches](/2.0/docs/patcher/concepts/patches) if applicable to adopt those changes.
 
 ## IaC foundations considerations
 
diff --git a/docs/2.0/docs/patcher/guides/promotion-workflows.md b/docs/2.0/docs/patcher/guides/promotion-workflows.md
@@ -5,8 +5,8 @@ As of July 2024 Gruntwork officially supports Patcher Promotion Workflows using
 
 :::info
 Related Content:
-* [Concepts - Patcher Workflows](../concepts/promotion-workflows.md)
-* [Architecture - Overview](../architecture/index.md)
+* [Concepts - Patcher Workflows](/2.0/docs/patcher/concepts/promotion-workflows)
+* [Architecture - Overview](/2.0/docs/patcher/architecture)
 :::
 
 ## Prerequisites
@@ -27,7 +27,7 @@ Then you would define your environments as `dev-*`, stage as `stage-*` and prod
 
 ## Implementation & Setup Example
 
-The Patcher Promotion Workflow process consists of a series of GitHub Actions workflow files.  Each environment is modeled as an individual workflow.  The process begins with the lowest environment (usually something like `dev`). It scans the entire `dev` environment for all dependencies which may require updates.  It then generates one pull request per dependency. That PR updates that dependency in just the `dev` environment.  
+The Patcher Promotion Workflow process consists of a series of GitHub Actions workflow files.  Each environment is modeled as an individual workflow.  The process begins with the lowest environment (usually something like `dev`). It scans the entire `dev` environment for all dependencies which may require updates.  It then generates one pull request per dependency. That PR updates that dependency in just the `dev` environment.
 
 As each of those pull requests is approved and merged, that approval triggers new pull requests for the subsequent environment (triggered via `repository dispatch` events).  This process continues until the last environment at which point no further PRs are opened and all environments have been updated.
 
@@ -49,7 +49,7 @@ The initial GitHub Actions Workflow file, in this example `update-dev.yml`, cont
     * Note this job uses a secret, `PIPELINES_READ_TOKEN`, which needs access to your Gruntwork account to access the Patcher binary.  See more on machine user tokens [here](/2.0/docs/pipelines/installation/viamachineusers).
 * The `update-env` Job
     * This job takes the spec output from the report, puts it into a file, then calls patcher update.
-    * Patcher update reads the spec file, checks out the code, makes a commit and then pushes a pull request    
+    * Patcher update reads the spec file, checks out the code, makes a commit and then pushes a pull request
     * It is critically important for the pull request workflow that the `pull_request_branch` be defined as `$PREFIX$DEPENDENCYID`. We strip out the prefix to identify the dependency ID in the `trigger-next-env` Job.
 <!-- spell-checker: disable -->
 ```yml
diff --git a/docs/2.0/docs/patcher/guides/update.md b/docs/2.0/docs/patcher/guides/update.md
@@ -77,7 +77,7 @@ Non-interactive mode supports both the `next-safe` and `next-breaking` update st
 
 ### Next Safe (Default)
 
-Using the [next safe update strategy](../concepts/update-strategies/#next-safe-update-strategy-default), if Patcher encounters a breaking change that it cannot patch then it will update the dependencies to the highest version **before** that breaking change. Otherwise, it will update the dependencies the latest version of that module.
+Using the [next safe update strategy](/2.0/docs/patcher/concepts/update-strategies/#next-safe-update-strategy-default), if Patcher encounters a breaking change that it cannot patch then it will update the dependencies to the highest version **before** that breaking change. Otherwise, it will update the dependencies the latest version of that module.
 
 Example usage:
 ```
diff --git a/docs/2.0/docs/pipelines/concepts/cloud-auth.md b/docs/2.0/docs/pipelines/concepts/cloud-auth.md
@@ -8,11 +8,11 @@ Pipelines can intelligently figure out which AWS account to authenticate to base
 
 To perform the actions that Pipelines detects, each AWS account needs to assume an AWS IAM Role using [OIDC](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services). To explain OIDC at a high level, AWS considers GitHub an "identity provider," trusts GitHub's request for a temporary IAM Role, and then issues AWS credentials that are valid for the duration of a GitHub Action workflow.
 
-Every time you create a new AWS account, you need to update the AWS OIDC configuration to create an IAM role for this account and allow it to be assumed by GitHub. When you use [Gruntwork Account Factory](../../accountfactory/architecture/index.md), this role is automatically created when [adding a new AWS account](/2.0/docs/accountfactory/guides/vend-aws-account).
+Every time you create a new AWS account, you need to update the AWS OIDC configuration to create an IAM role for this account and allow it to be assumed by GitHub. When you use [Gruntwork Account Factory](/2.0/docs/accountfactory/architecture), this role is automatically created when [adding a new AWS account](/2.0/docs/accountfactory/guides/vend-aws-account).
 
 ### How Pipelines knows what AWS account to authenticate to
 
-Pipelines assumes that each top level directory in your `infrastructure-live` repository maps to a single AWS account, excluding the directory used for [module defaults](../../library/concepts/module-defaults.md). Each account-mapped directory must have an entry in the `/accounts.yml` file with a key matching the directory name and containing key/value pairs for the AWS account ID and the account's root user email address.
+Pipelines assumes that each top level directory in your `infrastructure-live` repository maps to a single AWS account, excluding the directory used for [module defaults](/2.0/docs/library/concepts/module-defaults). Each account-mapped directory must have an entry in the `/accounts.yml` file with a key matching the directory name and containing key/value pairs for the AWS account ID and the account's root user email address.
 
 For example, the following entry in `accounts.yml` would be mapped to a directory called `my-cool-account` in your `infrastructure-live` repository.
 
diff --git a/docs/2.0/docs/pipelines/configuration/driftdetection.md b/docs/2.0/docs/pipelines/configuration/driftdetection.md
@@ -3,4 +3,4 @@
 
 If you're a Pipelines Enterprise customer and you installed Pipelines using our infrastructure-live-root repository template then Drift Detection is already installed and available as a GitHub workflow in your repository.
 
-If you installed Pipelines in a manner other than from the template and you're an enterprise customer and you want to add Drift Detection, see the [Installing Drift Detection Guide](../guides/installing-drift-detection.md).
+If you installed Pipelines in a manner other than from the template and you're an enterprise customer and you want to add Drift Detection, see the [Installing Drift Detection Guide](/2.0/docs/pipelines/guides/installing-drift-detection.md).
diff --git a/docs/2.0/docs/pipelines/guides/managing-secrets.md b/docs/2.0/docs/pipelines/guides/managing-secrets.md
@@ -9,13 +9,13 @@ credentials whenever possible. This is done to minimize the risk of long lived s
 easier to rotate secrets when necessary.
 
 The only long lived credentials that you are required to create, rotate and maintain to use Pipelines are the
-credentials used to authenticate as your [GitHub Machine users](../installation/viamachineusers.md). We are constantly looking for ways
+credentials used to authenticate as your [GitHub Machine users](/2.0/docs/pipelines/installation/viamachineusers). We are constantly looking for ways
 to improve the security posture of Pipelines, and are actively working on ways to reduce even this minimal requirement.
 
 ## Authenticating With GitHub
 
 To authenticate with GitHub, 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 how you installed Pipelines) to authenticate and interact with the GitHub API. You can
-learn more about how these tokens are created and managed in the [Machine Users](../installation/viamachineusers.md) documentation.
+learn more about how these tokens are created and managed in the [Machine Users](/2.0/docs/pipelines/installation/viamachineusers) documentation.
 
 ## Authenticating With AWS
 
diff --git a/docs/2.0/docs/pipelines/guides/setup-delegated-repo.mdx b/docs/2.0/docs/pipelines/guides/setup-delegated-repo.mdx
diff --git a/docs/2.0/docs/pipelines/installation/addingnewrepo.md b/docs/2.0/docs/pipelines/installation/addingnewrepo.md
diff --git a/docs/2.0/docs/pipelines/installation/prerequisites/awslandingzone.md b/docs/2.0/docs/pipelines/installation/prerequisites/awslandingzone.md
diff --git a/docs/2.0/docs/pipelines/previous-versions/upgrading-from-ecs-deploy-runner.md b/docs/2.0/docs/pipelines/previous-versions/upgrading-from-ecs-deploy-runner.md
diff --git a/docs/2.0/docs/pipelines/previous-versions/upgrading-from-infrastructure-pipelines.md b/docs/2.0/docs/pipelines/previous-versions/upgrading-from-infrastructure-pipelines.md
diff --git a/package.json b/package.json

Original file line number	Diff line number	Diff line change
`@@ -21,4 +21,3 @@ To learn more, refer to [Modules](/2.0/docs/library/concepts/modules)`
`21`	`21`	Service modules are opinionated combinations of "building block" modules described above. They are designed to be used "off the shelf" with no need to assemble a collection of “building block” modules on your own. They typically represent a full use case to solve a business problem on their own. For example, the `vpc` service module deploys a VPC, VPC Flow Logs, and Network ACLs. If you agree with the opinions embedded in a service module, they’re the fastest way to deploy production-grade infrastructure.
`22`	`22`
`23`	`23`	`To learn more, refer to [Service Modules](/2.0/docs/library/concepts/service-modules)`
`24`		`-`
Original file line number	Diff line number	Diff line change
`@@ -77,4 +77,4 @@ For more details and the other options, see [Keep your Terragrunt Architecture D`
`77`	`77`	`### Module defaults`
`78`	`78`
`79`	`79`
`80`		-Now that you have your accounts, environments, categories, resources, and state figured out, you may be wondering how you can increase code re-use across your `live` repository. Gruntwork recommends using the ["module defaults"](../../library/concepts/module-defaults.md) pattern to keep your Terragrunt architecture DRY.
	`80`	+Now that you have your accounts, environments, categories, resources, and state figured out, you may be wondering how you can increase code re-use across your `live` repository. Gruntwork recommends using the ["module defaults"](/2.0/docs/library/concepts/module-defaults) pattern to keep your Terragrunt architecture DRY.