fix GitHub and GitLab spelling to a correct one

Signed-off-by: George Gaál <[email protected]>

Author: gecube

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
 

docs/ce/features/opa-policies.mdx

@@ -17,7 +17,7 @@ With plan policies you can check `terraform plan` output for compliance with you
 
 With access policies you can control which Digger operations are allowed at any given time based on various inputs. Access policy is checked before every plan and apply and is passed the following data:
 
-- user id (from github)
+- user id (from GitHub)
 - plan policy violations, if any
 - list of users who approved the PR
 

docs/ce/features/plan-persistence.mdx

@@ -2,4 +2,4 @@
 title: "Plan Persistence"
 ---
 
-By default digger will run an apply based on the branch pull request files (no artefacts stored). In order to configure plan artefacts you can configure the inputs for storing as github artefacts or aws buckets or gcp buckets. The corresponding artefacts to be configured can be found in [storing plans in a bucket](/ce/howto/store-plans-in-a-bucket)
+By default digger will run an apply based on the branch pull request files (no artefacts stored). In order to configure plan artefacts you can configure the inputs for storing as GitHub artefacts or aws buckets or gcp buckets. The corresponding artefacts to be configured can be found in [storing plans in a bucket](/ce/howto/store-plans-in-a-bucket)

docs/ce/features/plan-preview.mdx

@@ -17,4 +17,4 @@ You can also re-plan by commenting `digger plan` (see [CommentOps](/features/com
 
 * By performing locks on pull request we guarantee that the plan preview on the pull request is not stale. i.e. the infrastructure was not touched by another subsequent change
 
-* Code in github: [https://github.com/diggerhq/digger/blob/5815775095d7380281c71c7c3aa63ca1b374365f/pkg/digger/digger.go#L228](https://github.com/diggerhq/digger/blob/5815775095d7380281c71c7c3aa63ca1b374365f/pkg/digger/digger.go#L228)
+* Code in GitHub: [https://github.com/diggerhq/digger/blob/5815775095d7380281c71c7c3aa63ca1b374365f/pkg/digger/digger.go#L228](https://github.com/diggerhq/digger/blob/5815775095d7380281c71c7c3aa63ca1b374365f/pkg/digger/digger.go#L228)

docs/ce/features/private-runners.mdx

@@ -4,7 +4,7 @@ title: "Private Runners"
 
 In many situations you wish to run digger with private runners. For example if you are provisioning resources in a private k8s cluster in this case you will not be able to use cloud runners.
 
-While digger does not natively support k8s agents it is very easy to do it indirectly using github actions runners.
+While digger does not natively support k8s agents it is very easy to do it indirectly using GitHub actions runners.
 In the typical digger flow you are using a workflow that looks like this:
 
 ```
@@ -16,8 +16,8 @@ jobs:
     runs-on: ubuntu-latest
 ```
 
-With github specifically there is good support for [self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners)
-which means that you can create agents for github actions in your private infrastructure's VPC and github will then run the jobs there.
+With GitHub specifically there is good support for [self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners)
+which means that you can create agents for GitHub actions in your private infrastructure's VPC and GitHub will then run the jobs there.
 
 The easiest way to achieve self-hosted runners is by running the agent in something like an EC2 instance. Alternatively if you already have a kubernetes cluster
 you could opt for using the [Actions runner controller](which will provide you with actions right in your cluster). Once you have set up and configured your controllers

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 [email protected]
 --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:
 

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)
 

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!)
 

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`

docs/ce/getting-started/gitlab-pipelines-+-aws.mdx

@@ -11,13 +11,13 @@ title: "GitLab Pipelines + AWS"
 
 ### Configuring and Deploying AWS Lambda: Step-by-Step Guide
 
-1. Fork and clone this repo: [https://github.com/diggerhq/gitlab-webhook-lambda](https://github.com/diggerhq/gitlab-webhook-lambda).
+1. Fork and clone this repo: [https://github.com/diggerhq/GitLab-webhook-lambda](https://github.com/diggerhq/GitLab-webhook-lambda).
 
 2. If necessary, update the `serverless.yml` file in the cloned repository. This file contains configuration settings for the Lambda function and can be customized to suit your requirements.
 
-3. Save the `GITLAB_TOKEN`to the SSM (Systems Manager) parameter store. You can choose any path for storing the token, but ensure that the `serverless.yml` file is updated accordingly if you deviate from the default path. For example, save the `GITLAB_TOKEN`to `ssm:/gitlab-dev-webhook-handler/dev/GITLAB_TOKEN`.
+3. Save the `GITLAB_TOKEN`to the SSM (Systems Manager) parameter store. You can choose any path for storing the token, but ensure that the `serverless.yml` file is updated accordingly if you deviate from the default path. For example, save the `GITLAB_TOKEN`to `ssm:/GitLab-dev-webhook-handler/dev/GITLAB_TOKEN`.
 
-4. Do the same for SECRET\_TOKEN, update serverless.yml if needed and save token value to ssm parameter (for example `ssm:/gitlab-dev-webhook-handler/dev/SECRET_TOKEN`)
+4. Do the same for SECRET\_TOKEN, update serverless.yml if needed and save token value to ssm parameter (for example `ssm:/GitLab-dev-webhook-handler/dev/SECRET_TOKEN`)
 
 5. Make sure that your AWS credentials are properly configured in the command-line interface (CLI). This ensures that you have the necessary permissions to deploy the Lambda function.