fix GitHub and GitLab spelling to a correct one

gecube · gecube · commit cacd913bebed · 2025-07-04T10:58:19.000+02:00
Signed-off-by: George Gaál &lt;gb12335@gmail.com&gt;
diff --git a/docs/ce/azure-specific/azure.mdx b/docs/ce/azure-specific/azure.mdx
@@ -14,7 +14,7 @@ Click "Go to Resource"; go to Access keys (on the lefthand side)
 
 Click "show" on the connection string. Copy and save it securely; it will be needed later in this guide.
 
-## 2\. Add Azure keys to Github Actions Secrets
+## 2\. Add Azure keys to GitHub Actions Secrets
 
 ### In Azure
 
@@ -32,7 +32,7 @@ Go to Certificates and Secrets. Click New Client Secret. Give it a name; click A
 
 Go to **subscription** in the portal and select your subscription ID, select **Access Control (IAM)** and **Add** the **Role assignment**, **Contributor** to your Service Principal. Take note of your Subscription ID value
 
-### In Github
+### In GitHub
 
 - Go to Settings → Secrets and Variables
 
diff --git a/docs/ce/gcp/federated-oidc-access.mdx b/docs/ce/gcp/federated-oidc-access.mdx
@@ -15,7 +15,7 @@ gcloud iam workload-identity-pools create github-wif-pool --location="global" --
 
 ## 2\. Create a Workload Identity Provider
 
-A Workload Identity Provider links an external identity like Github with your Google Cloud account. This lets IAM use tokens from external providers to authorize access to Google Cloud resources.
+A Workload Identity Provider links an external identity like GitHub with your Google Cloud account. This lets IAM use tokens from external providers to authorize access to Google Cloud resources.
 
 ```
 gcloud iam workload-identity-pools providers create-oidc githubwif \
@@ -27,7 +27,7 @@ gcloud iam workload-identity-pools providers create-oidc githubwif \
 
 ## 3\. Create a Service Account and bind policies
 
-A service account with relevant permissions will be impersonated by WIF. This allows Github action to impersonate the service account and get a token.
+A service account with relevant permissions will be impersonated by WIF. This allows GitHub action to impersonate the service account and get a token.
 
 ```
 gcloud iam service-accounts create test-wif \
@@ -43,7 +43,7 @@ gcloud iam service-accounts add-iam-policy-binding test-wif@.iam.gserviceaccount
 --member="principalSet://iam.googleapis.com/projects//locations/global/workloadIdentityPools/github-wif-pool/attribute.repository/PradeepSingh1988/gcp-wif"
 ```
 
-## 4\. Add secrets to Github
+## 4\. Add secrets to GitHub
 
 Create 2 secrets in your Action Secrets with the following names:
 
diff --git a/docs/ce/gcp/setting-up-gcp-+-gh-actions.mdx b/docs/ce/gcp/setting-up-gcp-+-gh-actions.mdx
@@ -19,7 +19,7 @@ Let's create our first pull request with a change and see this in action:
 
 ![](images/configuration/2.webp)
 
-4.  Add environment variables into your Github Action Secrets (cloud keys are a requirement since digger needs to connect to your account for coordinating locks). Use[ this guide](https://developers.google.com/workspace/guides/create-credentials) to get the value for it:  
+4.  Add environment variables into your GitHub Action Secrets (cloud keys are a requirement since digger needs to connect to your account for coordinating locks). Use[ this guide](https://developers.google.com/workspace/guides/create-credentials) to get the value for it:  
   
 ![](/images/gcp/1.png)
 
diff --git a/docs/ce/getting-started/github-actions-+-aws.mdx b/docs/ce/getting-started/github-actions-+-aws.mdx
@@ -1,8 +1,8 @@
 ---
-title: "Github Actions + AWS"
+title: "GitHub Actions + AWS"
 ---
 
-In this tutorial, you will set up Digger to automate terraform pull requests using Github Actions and AWS
+In this tutorial, you will set up Digger to automate terraform pull requests using GitHub Actions and AWS
 
 # Prerequisites
 
@@ -34,7 +34,7 @@ projects:
   dir: prod
 ```
 
-# Create Github Actions workflow file
+# Create GitHub Actions workflow file
 
 Place it at `.github/workflows/digger_workflow.yml` (name is important!)
 
diff --git a/docs/ce/getting-started/github-actions-and-gcp.mdx b/docs/ce/getting-started/github-actions-and-gcp.mdx
@@ -1,8 +1,8 @@
 ---
-title: "Github Actions + GCP"
+title: "GitHub Actions + GCP"
 ---
 
-In this tutorial, you will set up Digger to automate terraform pull requests using Github Actions and GCP.
+In this tutorial, you will set up Digger to automate terraform pull requests using GitHub Actions and GCP.
 
 # Prerequisites
 
@@ -33,7 +33,7 @@ projects:
   dir: prod
 ```
 
-# Create Github Actions workflow file
+# Create GitHub Actions workflow file
 
 Place it at `.github/workflows/digger_workflow.yml` (name is important!)
 
@@ -87,7 +87,7 @@ jobs:
 
 This file defines a workflow with 5 steps:
 
-- Checkout repository using Github's official [Checkout action](https://github.com/actions/checkout)
+- Checkout repository using GitHub's official [Checkout action](https://github.com/actions/checkout)
 - Authenticate into GCP using Google's official [Auth action](https://github.com/google-github-actions/auth). Note the `create_credentials_file: true` option; without it, subsequent steps that rely [Application Default Credentials](https://cloud.google.com/docs/authentication/provide-credentials-adc) will not work.
 - Set up Google Cloud SDK for use in the subsequent steps via Google's official [Setup-gcloud action](https://github.com/google-github-actions/setup-gcloud)
 - Verify that GCP is configured correctly by running `gcloud info`
diff --git a/docs/ce/howto/store-plans-in-a-bucket.mdx b/docs/ce/howto/store-plans-in-a-bucket.mdx
@@ -2,8 +2,8 @@
 title: "Store plans in a Bucket"
 ---
 
-### Github 
-Digger can use Github Artifacts to store `terraform plan` outputs. In order to enable it you can set the following argument in digger_workflow.yml:
+### GitHub 
+Digger can use GitHub Artifacts to store `terraform plan` outputs. In order to enable it you can set the following argument in digger_workflow.yml:
 
 ```
 upload-plan-destination: github
diff --git a/docs/ce/reference/digger.yml.mdx b/docs/ce/reference/digger.yml.mdx
@@ -246,7 +246,7 @@ Workflow configuration describes how to react to CI events. It has 3 sections:
 
 A project in Digger corresponds to a directory containing Terraform code. Projects are treated as standalone independent entities with their own locks. Digger will not prevent you from running plan and apply in different projects simultaneously.
 
-You can run plan / apply in a specified project by using the -p option in Github PR comment:
+You can run plan / apply in a specified project by using the -p option in GitHub PR comment:
 
 ```bash
 digger apply -p my-second-app
diff --git a/docs/ce/self-host/deploy-binary.mdx b/docs/ce/self-host/deploy-binary.mdx
@@ -11,7 +11,7 @@ This guide describes self-hosting the orchestrator backend as a binary aka "roll
   open source (Apache 2.0 license) ([repo on
   GitHub](https://github.com/diggerhq/digger)). You do not need a license or an
   account on Digger Cloud to self-host Digger CE. If you require
-  enterprise-grade features like Github Enterprise Server support, SSO / SAML,
+  enterprise-grade features like GitHub Enterprise Server support, SSO / SAML,
   multi-team / multi-org - [Talk to
   us](https://calendly.com/diggerdev/digger-open-source-terraform-cloud-alternativ-clone)
 </Note>
diff --git a/docs/ce/self-host/deploy-docker-compose.mdx b/docs/ce/self-host/deploy-docker-compose.mdx
@@ -7,7 +7,7 @@ Digger has 2 main components: the CLI that runs within your CI and an orchestrat
 This guide describes self-hosting the orchestrator backend as a binary aka "roll your own". Self-hosting may come handy when using the cloud-based version of it is not an option (for example due to compliance requirements). More guides (docker, EC2, etc) are coming soon.
 
 <Note>
-This guide is about self-hosting Digger Community Edition which is free and open source (Apache 2.0 license) ([repo on GitHub](https://github.com/diggerhq/digger)). You do not need a license or an account on Digger Cloud to self-host Digger CE. If you require enterprise-grade features like Github Enterprise Server support, SSO / SAML, multi-team / multi-org - [Talk to us](https://calendly.com/diggerdev/digger-open-source-terraform-cloud-alternativ-clone)
+This guide is about self-hosting Digger Community Edition which is free and open source (Apache 2.0 license) ([repo on GitHub](https://github.com/diggerhq/digger)). You do not need a license or an account on Digger Cloud to self-host Digger CE. If you require enterprise-grade features like GitHub Enterprise Server support, SSO / SAML, multi-team / multi-org - [Talk to us](https://calendly.com/diggerdev/digger-open-source-terraform-cloud-alternativ-clone)
 </Note>
 
 # Prerequisites
diff --git a/docs/ce/self-host/deploy-docker.mdx b/docs/ce/self-host/deploy-docker.mdx
@@ -7,7 +7,7 @@ Digger has 2 main components: the CLI that runs within your CI and an orchestrat
 This guide describes self-hosting the orchestrator backend as a binary aka "roll your own". Self-hosting may come handy when using the cloud-based version of it is not an option (for example due to compliance requirements). More guides (docker, EC2, etc) are coming soon.
 
 <Note>
-This guide is about self-hosting Digger Community Edition which is free and open source (Apache 2.0 license) ([repo on GitHub](https://github.com/diggerhq/digger)). You do not need a license or an account on Digger Cloud to self-host Digger CE. If you require enterprise-grade features like Github Enterprise Server support, SSO / SAML, multi-team / multi-org - [Talk to us](https://calendly.com/diggerdev/digger-open-source-terraform-cloud-alternativ-clone)
+This guide is about self-hosting Digger Community Edition which is free and open source (Apache 2.0 license) ([repo on GitHub](https://github.com/diggerhq/digger)). You do not need a license or an account on Digger Cloud to self-host Digger CE. If you require enterprise-grade features like GitHub Enterprise Server support, SSO / SAML, multi-team / multi-org - [Talk to us](https://calendly.com/diggerdev/digger-open-source-terraform-cloud-alternativ-clone)
 </Note>
 
 # Prerequisites
diff --git a/docs/ce/self-host/self-host-on-azure.mdx b/docs/ce/self-host/self-host-on-azure.mdx
@@ -133,7 +133,7 @@ For GitHub Actions with OIDC (which is likely what you're setting up), you'll al
      - `AZURE_TENANT_ID`
      - `AZURE_SUBSCRIPTION_ID`
 
-## Configure Github workflow:
+## Configure GitHub workflow:
 
 create this github workflow in your repository under `.github/workflow/digger_workflow.yml`
 
diff --git a/docs/ee/buildkite.mdx b/docs/ee/buildkite.mdx
@@ -3,7 +3,7 @@ title: "Buildkite CI backend"
 ---
 
 You can use digger with buildkite as a CI backend. Currently this is an EE feature only.
-Github is the VCS which is supported with this flow.
+GitHub is the VCS which is supported with this flow.
 
 ### Prerequisites:
 
diff --git a/docs/ee/drift-detection.mdx b/docs/ee/drift-detection.mdx
@@ -51,7 +51,7 @@ Note the `DRIFT_DETECTION_SLACK_NOTIFICATION` env var that the workflow above is
 
 Follow the [official Slack guide](https://api.slack.com/messaging/webhooks) to get the Incoming Webhook URL; then add it as an Action secret named `DRIFT_DETECTION_SLACK_NOTIFICATION`
 
-## Gitlab
+## GitLab
 
 For using drift detection with gitlab, a similar workflow can be used:
 
diff --git a/docs/ee/gitlab-support.mdx b/docs/ee/gitlab-support.mdx
@@ -1,5 +1,5 @@
 ---
-title: "Gitlab CI and Pipelines"
+title: "GitLab CI and Pipelines"
 ---
 
 You can use digger with gitlab as your VCS and gitlab pipelines as a CI backend. Currently this is an EE feature only.
@@ -18,7 +18,7 @@ with some differences:
 
 - For the docker image you will need to use the ee image: https://github.com/diggerhq/digger/pkgs/container/digger_backend
 - You will need to include the license key environment variable to the backend and the cli: `DIGGER_LICENSE_KEY=xxxyyy`
-- You can ignore all the steps regarding setting up Github app and all GITHUB_** environment variables
+- You can ignore all the steps regarding setting up GitHub app and all GITHUB_** environment variables
 - For gitlab CI configuration you need to specify the following environment variables:
 
 ```
@@ -110,7 +110,7 @@ gitlab should also trigger and also perform a plan. If successful the job will c
 
 ## Repo allowlist
 
-You can set `DIGGER_REPO_ALLOW_LIST` env variable on the server to define a whitelist of repositories allowed to trigger Digger workflows in Gitlab. This is needed because unlike GitHub, there's no concept of "apps" in Gitlab to allow granular control of per-repo access.
+You can set `DIGGER_REPO_ALLOW_LIST` env variable on the server to define a whitelist of repositories allowed to trigger Digger workflows in GitLab. This is needed because unlike GitHub, there's no concept of "apps" in GitLab to allow granular control of per-repo access.
 
 ```
 DIGGER_REPO_ALLOW_LIST=gitlab.com/diggerdev/digger-demo,gitlab.com/diggerdev/alsoallowed
diff --git a/docs/ee/gitlab.mdx b/docs/ee/gitlab.mdx
@@ -1,23 +1,23 @@
 ---
-title: "Gitlab Pipelines"
+title: "GitLab Pipelines"
 ---
 
 
-You can use Digger with Gitlab as your VCS and Gitlab pipelines as a CI backend. Currently this is an EE feature only.
+You can use Digger with GitLab as your VCS and GitLab pipelines as a CI backend. Currently this is an EE feature only.
 
 ### Prerequisites:
 
 - Having a valid Digger EE license key. This needs to be provided by us, please [contact us](https://digger.dev/pricing) to request it
-- A Gitlab account.
-- A personal Gitlab access token. This can be created from user preferences > access tokens
+- A GitLab account.
+- A personal GitLab access token. This can be created from user preferences > access tokens
 
 ### Install the digger EE orchestrator:
 
 You need to install the digger EE orchestrator. The installation steps are the same as the steps in [**self hosting docker**](https://docs.digger.dev/self-host/deploy-docker) with some differences:
 
 - For the docker image you will need to use the ee image: https://github.com/diggerhq/digger/pkgs/container/digger_backend_ee **(latest version, v0.6.5 as of this guide)**
 - You will need to include the license key environment variable to the backend and the cli: **`DIGGER_LICENSE_KEY=xxxyyy`**
-- You can ignore all the steps regarding setting up Github app and all GITHUB_** environment variables
+- You can ignore all the steps regarding setting up GitHub app and all GITHUB_** environment variables
 - For gitlab CI configuration you need to specify the following environment variables:
 
 ```jsx
@@ -39,13 +39,13 @@ projects:
     dir: dev/
 ```
 
-**Setting up Gitlab webhooks**
+**Setting up GitLab webhooks**
 
 In the repo where you are interested to integrate with digger you need to set up a webhook pointing to your digger hostname. Go to Settings > Webhooks and add digger host name. Set the secret token as “abc123” (same as **`DIGGER_GITLAB_WEBHOOK_SECRET`**) above. make sure that “Comments” and “Merge request events” are selected for Trigger events. Finally you can save.
 
 ### Create digger pipeline in your gitlab repo
 
-To create a Gitlab pipeline you can use a .gitlab-ci.yml file in the root of your file. In this you need to create a script which downloads Digger binary and invokes it, the purpose here is to have this pipeline triggered by Digger externally. Here is an example of such file:
+To create a GitLab pipeline you can use a .gitlab-ci.yml file in the root of your file. In this you need to create a script which downloads Digger binary and invokes it, the purpose here is to have this pipeline triggered by Digger externally. Here is an example of such file:
 
 ```jsx
 
@@ -91,7 +91,7 @@ This will instruct digger to run the “spec” which is composed and sent from
 
 In order to test your setup try to create a pull request in your repo. After you Comment “digger plan” You should see in the backend logs that a webhook event was received and an initial comment should be triggered in your pull request.
 
-Your Gitlab should also trigger and also perform a plan. If successful the job will comment back the plan as follows:
+Your GitLab should also trigger and also perform a plan. If successful the job will comment back the plan as follows:
 
 ![](/images/ee/gitlab-1.png)
 
diff --git a/docs/ee/multi-github.mdx b/docs/ee/multi-github.mdx
@@ -1,5 +1,5 @@
 ---
-title: "Multi Tenant Github Connections"
+title: "Multi Tenant GitHub Connections"
 ---
 
 
diff --git a/docs/readme/feedback.mdx b/docs/readme/feedback.mdx
@@ -6,7 +6,7 @@ We are always looking at feedback and suggestions from the community. If somethi
 please tell us. We are always keen on thoughts/feedback.
 
 
-Head over to [Github](https://github.com/diggerhq/digger/blob/develop/docs/readme/feedback.mdx) and raise a PR to add your feedback below (Optionally link to a github issue if you find it is relevant to your feedback)
+Head over to [GitHub](https://github.com/diggerhq/digger/blob/develop/docs/readme/feedback.mdx) and raise a PR to add your feedback below (Optionally link to a github issue if you find it is relevant to your feedback)
 
 ## To-do list (Issues, feedback and feature requests)
 
diff --git a/docs/readme/introduction.mdx b/docs/readme/introduction.mdx
@@ -29,6 +29,6 @@ Read more about differences with Atlantis in our [blog post](https://medium.com/
 
 ## Support for other CI's
 
-We are currently designing Digger to be Multi-CI, so that in addition to GitHub Actions, you can run Terraform/OpenTofu within other CI's such as Gitlab CI, Azure DevOps, Bitbucket, TeamCity, Circle CI and Jenkins, while still having the option to orchestrate jobs using Digger's [Orchestrator Backend](https://docs.digger.dev/self-host/deploy-docker).
+We are currently designing Digger to be Multi-CI, so that in addition to GitHub Actions, you can run Terraform/OpenTofu within other CI's such as GitLab CI, Azure DevOps, Bitbucket, TeamCity, Circle CI and Jenkins, while still having the option to orchestrate jobs using Digger's [Orchestrator Backend](https://docs.digger.dev/self-host/deploy-docker).
 
 Read more in this [blog](https://blog.digger.dev/how-we-are-designing-digger-to-support-multiple-ci-systems/), and please share your requirement on [Slack](https://bit.ly/diggercommunity) if you require support for other CI's. Your feedback/insight would help us a lot as this feature is in active development.
diff --git a/docs/readme/pricing.mdx b/docs/readme/pricing.mdx
@@ -23,7 +23,7 @@ title: "Pricing"
 | Drift Detection                  | ❌| ✅ |
 | RBAC via OPA                     | ❌| ✅ |
 | Org-level policies (OPA)         | ❌| ✅ |
-| Private VCS Support  - GitHub, Gitlab & Bitbucket         | ❌ | ✅ |
+| Private VCS Support  - GitHub, GitLab & Bitbucket         | ❌ | ✅ |
 | Audit Log Retention              | ❌ | ✅ |
 | Compliance Frameworks            | ❌ | ✅ |
 | 99.99% SLA                       | ❌ | ✅ |
@@ -41,9 +41,9 @@ Digger enterprise is for customers requiring access to the dashboard, SSO via SA
 
 **Which parts of Digger is Open Source?**
 
-All of Digger is open source, even the enterprise edition. The feature set of Digger cloud (GitHub App) and Digger community edition is exactly the same, the difference is only where it is hosted. Please note that Digger Cloud is GitHub Only, for Bitbucket & Gitlab you'd have to Self Manage it, unless you want a dedicated instance under an enterprise license.
+All of Digger is open source, even the enterprise edition. The feature set of Digger cloud (GitHub App) and Digger community edition is exactly the same, the difference is only where it is hosted. Please note that Digger Cloud is GitHub Only, for Bitbucket & GitLab you'd have to Self Manage it, unless you want a dedicated instance under an enterprise license.
 
-To self-host the enterprise edition, you'd need to buy a license (same as with Gitlab and other commercial open-source products). 
+To self-host the enterprise edition, you'd need to buy a license (same as with GitLab and other commercial open-source products). 
 
 **For anyone using Digger, are all of the enterprise features in the open source codebase?** 
 
@@ -53,7 +53,7 @@ Yes
 
 We ask users to bring their own compute and state management system as we believe that the number of privileged environments in an organisation needs to be kept to a minimum. The orchestrator backend, therefore, does not have access to your cloud account, states, plans, tfvars, or any other sensitive data. 
 
-For Digger Enterprise, users pay for Audit Log Retention, SAML, SSO & SCIM, Private VCS support (Github, Gitlab and Bitbucket), Compliance Frameworks and Enterprise Support. Book a [demo](https://calendly.com/diggerdev/diggerdemo) here if you’re interested.
+For Digger Enterprise, users pay for Audit Log Retention, SAML, SSO & SCIM, Private VCS support (GitHub, GitLab and Bitbucket), Compliance Frameworks and Enterprise Support. Book a [demo](https://calendly.com/diggerdev/diggerdemo) here if you’re interested.
 
 
 We truly value community feedback and suggestions. Feel free to join our [slack](https://bit.ly/diggercommunity) if you have any questions that aren’t answered above.
diff --git a/docs/team/getting-started/gha-aws.mdx b/docs/team/getting-started/gha-aws.mdx
@@ -33,7 +33,7 @@ Create a `digger_workflow.yml` file under `.github/workflows` in your repo with
 
 <Note>
   In order to be triggered, the workflow file with the exact same name must
-  exist in the default branch. Github will use the file from a relevant branch -
+  exist in the default branch. GitHub will use the file from a relevant branch -
   but it will throw a 404 error if a workflow with the same name is not found in
   the default branch.
 </Note>
