fix GitHub and GitLab spelling to a correct one

action.yml

@@ -106,7 +106,7 @@ inputs:
     required: false
     default: 'true'
   upload-plan-destination:
-    description: Destination to upload the plan to. azure, gcp, github and aws are currently supported.
+    description: Destination to upload the plan to. Azure, GCP, GitHub and aws are currently supported.
     required: false
   upload-plan-destination-s3-bucket:
     description: Name of the destination bucket for AWS S3. Should be provided if destination == aws

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-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 easy to achieve this indirectly with 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.
+GitHub provides first-class 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.
 

docs/ce/howto/apply-requirements.mdx

@@ -10,8 +10,8 @@ You can use mergeability requirements together with Status Checks to achieve the
 Digger will not apply if the pull request is not in a “mergeable” state as specified by GitHub api. This means that if you have a separate status check and you have this check as “required” by branch protection rules then an attempt of digger apply will not go ahead.
 
 Note: there is a [known issue](https://github.com/diggerhq/digger/issues/1180) that would
- cause the "mergability" check to conflict if you set the digger/apply check as required on github. We are working on a fix and in the meantime you have an option to turn off the mergability check if you want to have this digger/apply check as required. You can turn it off in the workflow configuration
-  by setting the `skip_merge_check` flag as follows (we have to set the other configurations since they are currently required):
+cause the "mergeability" check to conflict if you set the digger/apply check as required on GitHub. We are working on a fix and, meanwhile, you can turn off the mergeability check.
+You can turn it off in the workflow configuration  by setting the `skip_merge_check` flag as follows (we have to set the other configurations since they are currently required):
 
 ```
 projects:

docs/ce/howto/auto-merge.mdx

@@ -11,10 +11,10 @@ projects:
 - name: production
   dir: prod
 auto_merge: true
-auto_merge_strategy: "squash" # optional, only supported on github
+auto_merge_strategy: "squash" # optional, only supported on GitHub
 ```
 
-If you are using github VCS you can also specify
+If you are using GitHub VCS you can also specify
 `auto_merge_strategy` to define the type of strategy. Possible values are:
 
 - squash: for squash merge

docs/ce/howto/generate-projects.mdx

@@ -108,7 +108,7 @@ Here is a curl request for it as an example"
 
 Where repo_full_name is just a path to the repo
 branch is the branch you want to cache from (always this would be your default branch
-installation_id is your github installation ID and can be fetched from your github app settings (the place where you installed the app from)
+installation_id is your GitHub installation ID and can be fetched from your GitHub app settings (the place where you installed the app from)
 
 You should get back a response that the caching has been initiated and in the backend logs you will see logs about cloning. You should see an entry for that repo in the repos_cache table if things are successful.
 Now you can decide how often you want to refresh the cache and you can then set up a cron task to curl that endpoint for the periods that you want to refresh.

docs/ce/howto/project-level-roles.mdx

@@ -43,10 +43,10 @@ generate_projects:
 
 # Assume role with cognito identity
 
-The github action JWT token includes alot of useful fields such as `ref`, `sha`, `runner_environment` etc. however it is
+The GitHub action JWT token includes alot of useful fields such as `ref`, `sha`, `runner_environment` etc. however it is
 challenging to write an AWS trust policy to match for these fields since only `aud` and `sub` fields are supported. Using cognito
 identity it is possible to remap the fields into principal tags which allows them to be matched in the trust policy. More information
-about this is in this article: https://catnekaise.github.io/github-actions-abac-aws/cognito-identity/.
+about this is in this article: https://catnekaise.GitHub.io/GitHub-actions-abac-aws/cognito-identity/.
 
 If you wish to perform this mapping in digger you can specify an additional aws_cognito_oidc configuration as follows:
 

docs/ce/howto/store-plans-in-a-bucket.mdx

@@ -2,12 +2,11 @@
 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
-```
 
 ### GCP 
 You can also configure plan outputs to be uploaded to GCP Buckets instead. This is handy in case you want your plan outputs to stay within your organisation's approved storage providers for security or compliance reasons.

docs/ce/howto/trigger-directly.mdx

@@ -4,7 +4,7 @@ title: "Trigger workflow directly"
 
 By default Digger workflows are triggered by an orchestrator backend (Digger Cloud or self-hosted) that listens to events from GitHub and triggers jobs in Actions. Without an orchestrator backend it is not possible to start jobs in parallel, so all plans and applies have to run sequentially in one action job, which can be slow. Also without an orchestrator backend the action needs to start on every commit and every comment, even if there were no terraform changes; large monorepos this can get expensive.
 
-But in some scenarios e.g. small projects that have no need for concurrency, it might be easier to just use a standalone action triggered directly from GitHub events. You can achieve that by specifying triggers at the top of the workflow:
+But in some scenarios e.g. small projects that have no need for concurrency, it might be easier to just use a standalone action triggered directly from github.events. You can achieve that by specifying triggers at the top of the workflow:
 
 ```
 name: Digger Pull Request Workflow

docs/ce/reference/action-inputs.mdx

@@ -84,7 +84,7 @@ inputs:
     required: false
     default: 'true'
   upload-plan-destination:
-    description: Destination to upload the plan to. azure, gcp, github and aws are currently supported.
+    description: Destination to upload the plan to. Azure, GCP, GitHub and aws are currently supported.
     required: false
   upload-plan-destination-s3-bucket:
     description: Name of the destination bucket for AWS S3. Should be provided if destination == aws