Fix ./ links to absolute (#2217)

Author: Resonance1584

docs/2.0/docs/accountfactory/tutorials/modify-account.md

@@ -24,7 +24,7 @@ Below you'll find a table with common AWS account operations and the Gruntwork r
 | [Create a new Organization Unit](https://docs.aws.amazon.com/controltower/latest/userguide/create-new-ou.html) (OU)           | ❌               | ✅                     |
 | [Request a new account](/2.0/docs/accountfactory/guides/vend-aws-account)                                                                                                         | ✅               | ❌                     |
 | [Create a new account](/2.0/docs/accountfactory/guides/vend-aws-account)                                                                                                          | ✅               | ❌                     |
-| [Remove an account](./remove-account.md)                                                                                       | ✅               | ❌                     |
+| [Remove an account](/2.0/docs/accountfactory/tutorials/remove-account.md)                                                                                       | ✅               | ❌                     |
 | [Rename an account](https://docs.aws.amazon.com/controltower/latest/userguide/change-account-name.html)                       | ❌               | ✅                     |
 | [Update root account e-mail address](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-root-user.html) | ❌               | ✅                     |
 | [Modify account controls](https://docs.aws.amazon.com/controltower/latest/userguide/enable-controls-on-ou.html)               | ❌               | ✅                     |

docs/2.0/docs/library/concepts/modules.md

@@ -10,13 +10,13 @@ Let’s look at an example module. The [rds module](/reference/modules/terraform
 
 The module deploys a key element of an overall RDS deployment, but it's not a _complete_ RDS deployment. That's because the `rds` module does not include backup policies using AWS Backup (for disaster recovery), or RDS Proxy (to pool database connections), or CloudWatch alarms (to alert you when something goes wrong). These missing pieces are best thought of as building block modules themselves. Gruntwork has modules for `backup-plan`, `backup-vault`, and `rds-proxy` that can all be used in combination with the `rds` module.
 
-To see how Gruntwork gives you an off-the-shelf overall deployment with all the elements included, see [Service Modules](./service-modules).
+To see how Gruntwork gives you an off-the-shelf overall deployment with all the elements included, see [Service Modules](/2.0/docs/library/concepts/service-modules).
 
 ## Modules are optimized for control
 
 A module is designed to be small, narrow in scope, and highly reusable, like a building block. Modules give you _control_, but they may not give you _convenience_. You can use the building block modules for all kinds of use cases (high control), but if you want to deploy a complete piece of infrastructure, you still have to do the work of assembling the right modules (low convenience).
 
-To learn how you can optimize for convenience, see [Service Modules](./service-modules).
+To learn how you can optimize for convenience, see [Service Modules](/2.0/docs/library/concepts/service-modules).
 
 To learn more about the overall thought process behind building block modules versus service modules, see [Introducing: The Gruntwork Module, Service, and Architecture Catalogs](https://blog.gruntwork.io/introducing-the-gruntwork-module-service-and-architecture-catalogs-eb3a21b99f70).
 
@@ -26,7 +26,7 @@ Building block modules are fairly generic by design, so you won't typically depl
 
 For example, one module might deploy the control plane for Kubernetes and a separate module could deploy worker nodes; you may need to combine both modules together to deploy a Kubernetes cluster.
 
-We recommend our [Service Catalog](./service-modules) for common use cases, but our full module catalog is available if you have a more complex use case.
+We recommend our [Service Catalog](/2.0/docs/library/concepts/service-modules) for common use cases, but our full module catalog is available if you have a more complex use case.
 
 ## Where to find the building block modules
 

docs/2.0/docs/library/concepts/overview.md

@@ -14,11 +14,11 @@ Gruntwork IaC Library contains two types of modules:
 
 "Building block" modules (which we call simply **modules**) are "infrastructure building blocks" authored by Gruntwork and written in OpenTofu configuration files. They capture a singular best-practice pattern for specific pieces of infrastructure and are designed to be both limited in scope and highly reusable. They typically represent one part of a use case you want to accomplish. For example, the `vpc-flow-logs` module does not create a VPC, it only adds the VPC Flow Logs functionality to an existing VPC.
 
-To learn more, refer to [Modules](./modules)
+To learn more, refer to [Modules](/2.0/docs/library/concepts/modules)
 
 ### Service 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](./service-modules)
+To learn more, refer to [Service Modules](/2.0/docs/library/concepts/service-modules)
 

docs/2.0/docs/library/concepts/service-modules.md

@@ -1,6 +1,6 @@
 # Service Modules
 
-Service modules are combinations of [modules](./modules) covering a wide variety of use cases, including CI/CD, networking, container orchestration (EKS, ECS), and more.
+Service modules are combinations of [modules](/2.0/docs/library/concepts/modules) covering a wide variety of use cases, including CI/CD, networking, container orchestration (EKS, ECS), and more.
 
 Service modules are usually written in Terraform, represent a full use case, and are designed to be used "off the shelf."
 
@@ -16,15 +16,15 @@ Whereas "building block" modules are optimized for control, service modules are
 
 A service module reflects a complete Gruntwork opinion on how you should run a piece of infrastructure. Using a service module gives you the convenience of a single Terraform module that does everything you need, with Gruntwork maintaining the code.
 
-If you do not agree with our opinions, you can either [customize the module](/2.0/docs/library/tutorials/customizing-modules), or sacrifice convenience in favor of control and build your own module, possibly out of our [building block modules](./modules).
+If you do not agree with our opinions, you can either [customize the module](/2.0/docs/library/tutorials/customizing-modules), or sacrifice convenience in favor of control and build your own module, possibly out of our [building block modules](/2.0/docs/library/concepts/modules).
 
 ## When to use a service module
 
 Using a service module can save you time because Gruntwork has already pieced together individual building block modules and tested that they correctly reference each other.
 
 For example, the [eks-cluster service module](/reference/services/app-orchestration/amazon-eks) combines all the modules you need to run an EKS (Kubernetes) cluster in a typical production environment, including modules for the control plane, worker nodes, secrets management, log aggregation, alerting, and so on.
 
-If you need more flexibility than our services provide, then you can combine modules from our [module catalog](./modules#where-to-find-the-building-block-modules), your own modules, or open source modules to meet your specific use case.
+If you need more flexibility than our services provide, then you can combine modules from our [module catalog](/2.0/docs/library/concepts/modules#where-to-find-the-building-block-modules), your own modules, or open source modules to meet your specific use case.
 
 CIS customers also have access to the [terraform-aws-cis-service-catalog git repo](https://github.com/gruntwork-io/terraform-aws-service-catalog) to help ensure conformity to the [CIS AWS Foundations Benchmark](https://gruntwork.io/achieve-compliance/).
 
@@ -40,4 +40,4 @@ To browse the service catalog, see the [Library Reference](/library/reference) a
 
 ## How service modules are updated
 
-When [building block modules are updated](./modules#how-modules-are-updated), we propagate those updates to the service catalog. Keep in mind that there is sometimes a delay between when a "building block" module is updated and when that update is reflected in the service catalog.
+When [building block modules are updated](/2.0/docs/library/concepts/modules#how-modules-are-updated), we propagate those updates to the service catalog. Keep in mind that there is sometimes a delay between when a "building block" module is updated and when that update is reflected in the service catalog.

docs/2.0/docs/library/guides/versioning.md

@@ -119,4 +119,4 @@ inputs = {
 </TabItem>
 </Tabs>
 
-Once you start using versioned modules, it’s important to keep the modules up to date. Refer to the [Updating Modules](./updating-modules) guide to learn more.
+Once you start using versioned modules, it’s important to keep the modules up to date. Refer to the [Updating Modules](/2.0/docs/library/guides/updating-modules) guide to learn more.

docs/2.0/docs/overview/concepts/devopsfoundations.md

@@ -16,7 +16,7 @@ When you set up a new DevOps component, you also have access to guidance from Gr
 
 There are several DevOps components available today:
 
-* [Infrastructure-Live](./infrastructure-live.md): An opinionated structure for IaC repositories that includes a set of best practices for how to structure your OpenTofu code to keep things DRY at enterprise scale.
+* [Infrastructure-Live](/2.0/docs/overview/concepts/infrastructure-live.md): An opinionated structure for IaC repositories that includes a set of best practices for how to structure your OpenTofu code to keep things DRY at enterprise scale.
 * [Pipelines](/2.0/docs/pipelines/concepts/overview.md): A complete CI/CD pipeline for infrastructure code, a set of best practices for how to structure your OpenTofu code, and a set of scripts for managing the pipeline.
 * [Account Factory](/2.0/docs/accountfactory/concepts/): A set of automated workflows to provision new AWS accounts and apply compliance, security and infrastructure baselines to enforce business rules across many accounts.
 * [Patcher](/2.0/docs/patcher/concepts/): Identify out of date modules across your repositories and create pull requests that both updates versions and automatically refactors code to get through breaking changes without developer intervention.

docs/2.0/docs/overview/getting-started/link-github-id.md

@@ -26,7 +26,7 @@ Once you’ve linked your account, the notice on the home page will disappear an
 
 ## Next Steps
 
-Now that you've completed setting up your Gruntwork account, return to the [DevOps Foundations Getting Started Checklist](./index.md) to continue setting up your DevOps Foundations.
+Now that you've completed setting up your Gruntwork account, return to the [DevOps Foundations Getting Started Checklist](/2.0/docs/overview/getting-started/index.md) to continue setting up your DevOps Foundations.
 
 ## Related Knowledge Base Discussions
 

docs/2.0/docs/pipelines/architecture/audit-logs.md

@@ -1,6 +1,6 @@
 # Audit logs
 
-Gruntwork Pipelines provides an audit log of which GitHub user performed _what_ operation in your AWS accounts as a result of a [Pipelines Action](./actions.md).
+Gruntwork Pipelines provides an audit log of which GitHub user performed _what_ operation in your AWS accounts as a result of a [Pipelines Action](/2.0/docs/pipelines/architecture/actions.md).
 
 Accessing AWS environments from a CI/CD system is commonly done by assuming temporary credentials using [OpenID Connect (OIDC)](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services). Usage of shared credentials complicates the task of maintaining an accurate log of who did what in your AWS accounts. Gruntwork Pipelines solves this issue by leveraging [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) and a naming scheme based on context from the triggering Pipelines Action in GitHub. This setup associates every single API operation performed by Gruntwork Pipelines with a GitHub username and a pull request or branch. This allows your security team to quickly triage access related issues and perform analytics on usage patterns of individual users from your version control system in your AWS accounts.
 
@@ -12,7 +12,7 @@ Gruntwork Pipelines provides an audit log of which user performed what action in
 
 Logs are available for all operations performed in every AWS account by Gruntwork Pipelines. Gruntwork Pipelines takes advantage of [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) session names to clearly label all sessions with the GitHub user who requested the change and the pull request or branch that triggered the change.
 
-The `userIdentity` field in each CloudTrail event associated with API calls performed by Pipelines [Actions](./actions.md) will contain the session name. For example, if the GitHub user `SomeUserInYourOrg` made a pull request that was the 123rd pull request in your repository, an associated CloudTrail event would have information that looked like the following in the `userIdentity` field.
+The `userIdentity` field in each CloudTrail event associated with API calls performed by Pipelines [Actions](/2.0/docs/pipelines/architecture/actions.md) will contain the session name. For example, if the GitHub user `SomeUserInYourOrg` made a pull request that was the 123rd pull request in your repository, an associated CloudTrail event would have information that looked like the following in the `userIdentity` field.
 
 ```json
 {
@@ -51,7 +51,7 @@ Combined with a [query service](#querying-data), you can use data from CloudTrai
 
 ### Who gets logged
 
-Pipelines uses a naming scheme that combines the GitHub user who triggered the Pipelines [Action](./actions.md) and the pull request or branch from which the action was initiated. Pipelines will set the AWS STS session name according to the following format: `<GitHubUserName>-via-GWPipelines@(PR-<PullRequestNumber>|<branch name>)`.
+Pipelines uses a naming scheme that combines the GitHub user who triggered the Pipelines [Action](/2.0/docs/pipelines/architecture/actions.md) and the pull request or branch from which the action was initiated. Pipelines will set the AWS STS session name according to the following format: `<GitHubUserName>-via-GWPipelines@(PR-<PullRequestNumber>|<branch name>)`.
 
 Pipelines runs Pipelines Actions when a pull request is opened, updated, re-opened, or merged to the deploy branch (e.g., main). The naming scheme will use different values for pull request events and pushes to the deploy branch (e.g. merged PRs).
 

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

@@ -14,4 +14,4 @@ Due to our integration with [Dependabot](https://docs.github.com/en/code-securit
 
 ## Updating Customized Workflows
 
-Note that if you follow the instructions under [Extending Pipelines](./extending-pipelines.md), you may have incurred greater burden in maintaining updates to your customized workflows. If you decide to fork the [pipelines-workflows](https://github.com/gruntwork-io/pipelines-workflows) repository to customize your workflows, you will need to manually update your workflows to include the latest changes from the upstream repository. This can be done by following the instructions in the [GitHub documentation](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/syncing-a-fork), as long as you have not made changes that conflict with the upstream repository.
+Note that if you follow the instructions under [Extending Pipelines](/2.0/docs/pipelines/guides/extending-pipelines.md), you may have incurred greater burden in maintaining updates to your customized workflows. If you decide to fork the [pipelines-workflows](https://github.com/gruntwork-io/pipelines-workflows) repository to customize your workflows, you will need to manually update your workflows to include the latest changes from the upstream repository. This can be done by following the instructions in the [GitHub documentation](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/syncing-a-fork), as long as you have not made changes that conflict with the upstream repository.

docs/2.0/docs/pipelines/installation/authoverview.md

@@ -8,7 +8,7 @@ Gruntwork Pipelines needs to authenticate with GitHub for various reasons, inclu
   * (via Account Factory) Creating new repositories
   * (via Account Factory) Updating repository settings, e.g. enforcing branch protection
 
-Gruntwork provides two mechanisms to achieve this authentication: a [GitHub App](./viagithubapp.md) and a strategy of using CI Users (aka [Machine Users](./viamachineusers.md)) for generating/installing personal access tokens for pipelines to use.
+Gruntwork provides two mechanisms to achieve this authentication: a [GitHub App](/2.0/docs/pipelines/installation/viagithubapp.md) and a strategy of using CI Users (aka [Machine Users](/2.0/docs/pipelines/installation/viamachineusers.md)) for generating/installing personal access tokens for pipelines to use.
 
 Broadly the two approaches achieve the same result and core pipelines functionality will work with either mechanism.  There are, however, some features and benefits only available with authenticating using the GitHub app and as such it is our recommended approach. As we roll out new features to pipelines we endeavor to ensure they are available to both authentication mechanisms. However, we do anticipate that the list of features that are GitHub App exclusive will grow over time.