fix naming

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

Author: gecube

docs/ce/azure-specific/azure.mdx

@@ -73,7 +73,7 @@ on:
     types: [ closed, opened, synchronize, reopened ]
   issue_comment:
     types: [created]
-    if: contains(github.event.comment.body, 'digger')
+    if: contains(GitHub.event.comment.body, 'digger')
   workflow_dispatch:
 
 jobs:
@@ -87,16 +87,16 @@ jobs:
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         run: |
-          PR_URL="${{ github.event.issue.pull_request.url }}"
+          PR_URL="${{ GitHub.event.issue.pull_request.url }}"
           PR_NUM=${PR_URL}
           echo "Checking out from PR #$PR_NUM based on URL: $PR_URL"
           hub pr checkout $PR_NUM
-        if: github.event_name == 'issue_comment'
+        if: GitHub.event_name == 'issue_comment'
 
       - name: digger
         uses: diggerhq/digger@vLatest
         env:
-          GITHUB_CONTEXT: ${{ toJson(github) }}
+          GITHUB_CONTEXT: ${{ toJson(GitHub) }}
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           LOCK_PROVIDER: azure
           DIGGER_AZURE_AUTH_METHOD: CONNECTION_STRING

docs/ce/cloud-providers/authenticating-with-oidc-on-aws.mdx

@@ -36,6 +36,6 @@ jobs:
         **aws-role-to-assume: arn:aws:iam::{AccountID}:role/{RoleName}**
           aws-region: us-east-1
         env:
-          GITHUB_CONTEXT: ${{ toJson(github) }}
+          GITHUB_CONTEXT: ${{ toJson(GitHub) }}
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 ```

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/pr-level-locks.mdx

@@ -4,10 +4,10 @@ title: "PR-level locks"
 
 * For every pull request we perform a lock when the pull request is opened and unlocked when the pull request is merged, this is to avoid making a plan preview stale
 
-* For GCP locking is performed using buckets that are strongly consistent: [https://github.com/diggerhq/digger/blob/80289922227f225d887feb74749b4daef8b441f8/pkg/gcp/gcp\_lock.go#L13](https://github.com/diggerhq/digger/blob/80289922227f225d887feb74749b4daef8b441f8/pkg/gcp/gcp%5Flock.go#L13)
+* For GCP locking is performed using buckets that are strongly consistent: [https://GitHub.com/diggerhq/digger/blob/80289922227f225d887feb74749b4daef8b441f8/pkg/gcp/gcp\_lock.go#L13](https://GitHub.com/diggerhq/digger/blob/80289922227f225d887feb74749b4daef8b441f8/pkg/gcp/gcp%5Flock.go#L13)
 
 * These options are configured and the locking can be disabled entirely if it is not needed
 
-* The locking interface is very simple and is based on `Lock()` and `Unlock()` Operations [https://github.com/diggerhq/digger/blob/5815775095d7380281c71c7c3aa63ca1b374365f/pkg/locking/locking.go#L40](https://github.com/diggerhq/digger/blob/5815775095d7380281c71c7c3aa63ca1b374365f/pkg/locking/locking.go#L40)
+* The locking interface is very simple and is based on `Lock()` and `Unlock()` Operations [https://GitHub.com/diggerhq/digger/blob/5815775095d7380281c71c7c3aa63ca1b374365f/pkg/locking/locking.go#L40](https://GitHub.com/diggerhq/digger/blob/5815775095d7380281c71c7c3aa63ca1b374365f/pkg/locking/locking.go#L40)
 
 * A pull request acquires a lock for every project impacted by this PR and all dependant projects

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

@@ -10,17 +10,17 @@ If you already have configured GCP for that, skip to step 5.
 A Workload Identity Pool is an umbrella entity for managing access in GCP. The best practice is to have a dedicated pool for each non-GCP environment.
 
 ```
-gcloud iam workload-identity-pools create github-wif-pool --location="global" --project
+gcloud iam workload-identity-pools create GitHub-wif-pool --location="global" --project
 ```
 
 ## 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.
 
 ```
-gcloud iam workload-identity-pools providers create-oidc githubwif \
---location="global" --workload-identity-pool="github-wif-pool"  \
---issuer-uri="https://token.actions.githubusercontent.com" \
+gcloud iam workload-identity-pools providers create-oidc GitHubwif \
+--location="global" --workload-identity-pool="GitHub-wif-pool"  \
+--issuer-uri="https://token.actions.GitHubusercontent.com" \
 --attribute-mapping="attribute.actor=assertion.actor,google.subject=assertion.sub,attribute.repository=assertion.repository" \
 --project
 ```
@@ -40,7 +40,7 @@ gcloud projects add-iam-policy-binding  \
 gcloud iam service-accounts add-iam-policy-binding [email protected] \
 --project= \
 --role="roles/iam.workloadIdentityUser" \
---member="principalSet://iam.googleapis.com/projects//locations/global/workloadIdentityPools/github-wif-pool/attribute.repository/PradeepSingh1988/gcp-wif"
+--member="principalSet://iam.googleapis.com/projects//locations/global/workloadIdentityPools/GitHub-wif-pool/attribute.repository/PradeepSingh1988/gcp-wif"
 ```
 
 ## 4\. Add secrets to GitHub
@@ -53,19 +53,19 @@ Create 2 secrets in your Action Secrets with the following names:
 
 ## 5\. Configure Digger workflow to use federated access
 
-Set `EXT` env var instead of the usual key pair. See [oidc-gcp-example](https://github.com/diggerhq/digger-gcp-ocid-demo) repo for more detail. Sample config below:
+Set `EXT` env var instead of the usual key pair. See [oidc-gcp-example](https://GitHub.com/diggerhq/digger-gcp-ocid-demo) repo for more detail. Sample config below:
 
 ```
 - id: 'auth'
-        uses: 'google-github-actions/auth@v1'
+        uses: 'google-GitHub-actions/auth@v1'
         with:
           token_format: access_token
           workload_identity_provider: ${{ secrets.GCP_WORKLOAD_IDENTITY_PROVIDER }}
           service_account: ${{ env.GCP_SERVICE_ACCOUNT }}
           audience: google-wif
 
       - name: 'Set up Cloud SDK'
-        uses: 'google-github-actions/setup-gcloud@v1'
+        uses: 'google-GitHub-actions/setup-gcloud@v1'
 
       - name: 'Use gcloud CLI'
         run: |
@@ -75,7 +75,7 @@ Set `EXT` env var instead of the usual key pair. See [oidc-gcp-example](https://
         uses: diggerhq/digger@vLatest
         env:
           LOCK_PROVIDER: gcp
-          GITHUB_CONTEXT: ${{ toJson(github) }}
+          GITHUB_CONTEXT: ${{ toJson(GitHub) }}
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           GOOGLE_STORAGE_BUCKET: digger-lock2
 
@@ -85,7 +85,7 @@ Set `EXT` env var instead of the usual key pair. See [oidc-gcp-example](https://
 
 <Note>
   This article is based on [this
-  post](https://medium.com/google-cloud/how-does-the-gcp-workload-identity-federation-work-with-github-provider-a9397efd7158)
+  post](https://medium.com/google-cloud/how-does-the-gcp-workload-identity-federation-work-with-GitHub-provider-a9397efd7158)
   by Pradeep Kumar Singh
 </Note>
 ```

docs/ce/gcp/setting-up-gcp-+-gh-actions.mdx

@@ -4,12 +4,12 @@ title: "Setting up GCP + GH Actions"
 
 
 
-In this tutorial we will be using a repository in order to configure a terraform pipeline [https://github.com/diggerhq/digger-gcp-lock-demo](https://github.com/diggerhq/digger-gcp-lock-demo). In order to use GCP with Digger we follow the steps below:
+In this tutorial we will be using a repository in order to configure a terraform pipeline [https://GitHub.com/diggerhq/digger-gcp-lock-demo](https://GitHub.com/diggerhq/digger-gcp-lock-demo). In order to use GCP with Digger we follow the steps below:
 
 
 Let's create our first pull request with a change and see this in action:
 
-1. Fork the [demo repository](https://github.com/diggerhq/digger-gcp-lock-demo)
+1. Fork the [demo repository](https://GitHub.com/diggerhq/digger-gcp-lock-demo)
 
 2. Enable Actions (by default workflows won't trigger in a fork)
 

docs/ce/getting-started/azure-devops.mdx

@@ -38,7 +38,7 @@ For tutorial purposes the token is shown with full access. Don't do that in prod
 
 ## 2\. Set up Azure Function
 
-Clone [this repository](https://github.com/diggerhq/azure-devops-webhook-handler), then follow [this guide](https://learn.microsoft.com/en-us/azure/azure-functions/create-first-function-vs-code-python?pivots=python-mode-configuration) deploy the function to your azure account
+Clone [this repository](https://GitHub.com/diggerhq/azure-devops-webhook-handler), then follow [this guide](https://learn.microsoft.com/en-us/azure/azure-functions/create-first-function-vs-code-python?pivots=python-mode-configuration) deploy the function to your azure account
 
 ![](/images/getting-started/azure-devops-3.png)
 
@@ -71,7 +71,7 @@ Select the repository you want to integrate digger with. Add the following 4 eve
 
 ## 4\. Create digger.yml
 
-Follow the digger documentation to create digger.yml for your structure, it should be similar to this [demo digger.yml](https://github.com/diggerhq/digger%5Fdemo%5Fmultienv/blob/main/digger.yml)
+Follow the digger documentation to create digger.yml for your structure, it should be similar to this [demo digger.yml](https://GitHub.com/diggerhq/digger%5Fdemo%5Fmultienv/blob/main/digger.yml)
 
 The minimum you would need to define for digger is where all your terraform lives: