Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Sign up
Appearance settings

fix GitHub and GitLab spelling to a correct one #2008

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
gecube wants to merge 6 commits into diggerhq:develop
base: develop
Choose a base branch
Loading
from gecube:github-gitlab-naming
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion action.yml
View file Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
4 changes: 2 additions & 2 deletions docs/ce/azure-specific/azure.mdx
View file Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand All @@ -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

Expand Down
2 changes: 1 addition & 1 deletion docs/ce/features/opa-policies.mdx
View file Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
2 changes: 1 addition & 1 deletion docs/ce/features/plan-preview.mdx
View file Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)
6 changes: 3 additions & 3 deletions docs/ce/features/private-runners.mdx
View file Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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:

```
Expand All @@ -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
Expand Down
6 changes: 3 additions & 3 deletions docs/ce/gcp/federated-oidc-access.mdx
View file Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 \
Expand All @@ -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 \
Expand All @@ -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:

Expand Down
2 changes: 1 addition & 1 deletion docs/ce/gcp/setting-up-gcp-+-gh-actions.mdx
View file Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)

Expand Down
6 changes: 3 additions & 3 deletions docs/ce/getting-started/github-actions-+-aws.mdx
View file Open in desktop
Original file line number Diff line number Diff line change
@@ -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

Expand Down Expand Up @@ -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!)

Expand Down
8 changes: 4 additions & 4 deletions docs/ce/getting-started/github-actions-and-gcp.mdx
View file Open in desktop
Original file line number Diff line number Diff line change
@@ -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

Expand Down Expand Up @@ -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!)

Expand Down Expand Up @@ -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`
Expand Down
6 changes: 3 additions & 3 deletions docs/ce/getting-started/gitlab-pipelines-+-aws.mdx
View file Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
4 changes: 2 additions & 2 deletions docs/ce/howto/apply-requirements.mdx
View file Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand Down
4 changes: 2 additions & 2 deletions docs/ce/howto/auto-merge.mdx
View file Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion docs/ce/howto/generate-projects.mdx
View file Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
4 changes: 2 additions & 2 deletions docs/ce/howto/project-level-roles.mdx
View file Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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/.

Comment on lines +46 to 50
Copy link
Contributor

@coderabbitai coderabbitai bot Jul 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Restore lowercase URL & clean up "alot" / punctuation

Using capitals inside a GitHub Pages domain can break the link. Also, "alot" → "a lot", and commas added for readability.

-The GitHub action JWT token includes alot of useful fields such as `ref`, `sha`, `runner_environment` etc. however it is
+The GitHub Actions JWT token includes a lot of useful claims such as `ref`, `sha`, and `runner_environment`; however, it is
 ...
-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/.
📝 Committable suggestion

!!️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
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/.
The GitHub Actions JWT token includes a lot of useful claims such as `ref`, `sha`, and `runner_environment`; 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/.
🧰 Tools
🪛 LanguageTool

[uncategorized] ~46-~46: Possible missing comma found.
Context: ...ref, sha, runner_environment etc. however it is challenging to write an AWS trust...

(AI_HYDRA_LEO_MISSING_COMMA)

[uncategorized] ~46-~46: A comma might be missing here.
Context: ...sha, runner_environment` etc. however it is challenging to write an AWS trust po...

(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)

🤖 Prompt for AI Agents 
In docs/ce/howto/project-level-roles.mdx around lines 46 to 50, fix the URL by
converting the GitHub Pages domain to all lowercase to prevent broken links,
change "alot" to "a lot", and add commas for better readability in the sentence
describing the GitHub action JWT token fields.

If you wish to perform this mapping in digger you can specify an additional aws_cognito_oidc configuration as follows:

Expand Down
5 changes: 2 additions & 3 deletions docs/ce/howto/store-plans-in-a-bucket.mdx
View file Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
2 changes: 1 addition & 1 deletion docs/ce/howto/trigger-directly.mdx
View file Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion docs/ce/reference/action-inputs.mdx
View file Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
Loading
Loading

AltStyle によって変換されたページ (->オリジナル) /