You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/ce/cloud-providers/aws.mdx
+1-1
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
---
2
2
title: "Setting up DynamoDB Access for locks"
3
-
description: "Digger runs without a backend but uses a DynamoDB table to keep track of all the locks that are necessary for locking PR projects. On the first run in your AWS account digger checks for the presense of `DiggerDynamoDBLockTable` and it requires the following policy for the DynamoDB access:"
3
+
description: "Digger runs without a backend but uses a DynamoDB table to keep track of all the locks that are necessary for locking PR projects. On the first run in your AWS account digger checks for the presence of `DiggerDynamoDBLockTable` and it requires the following policy for the DynamoDB access:"
Copy file name to clipboardExpand all lines: docs/ce/gcp/federated-oidc-access.mdx
+1-1
Original file line number
Diff line number
Diff line change
@@ -53,7 +53,7 @@ Create 2 secrets in your Action Secrets with the following names:
53
53
54
54
## 5\. Configure Digger workflow to use federated access
55
55
56
-
Set `EXT` env var intead of the usual key pair. See [oidc-gcp-example](https://github.com/diggerhq/digger-gcp-ocid-demo) repo for more detail. Sample config below:
56
+
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:
Copy file name to clipboardExpand all lines: docs/ce/howto/apply-requirements.mdx
+1-1
Original file line number
Diff line number
Diff line change
@@ -7,4 +7,4 @@ Digger currently does not support `apply_requirements` (like in Atlantis). Comin
7
7
## Workaround
8
8
9
9
You can use mergeability requirements together with Status Checks to achieve the same.
10
-
Digger will not apply if the pull request is not in a “mergable” 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.
10
+
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.
Copy file name to clipboardExpand all lines: docs/ce/howto/project-level-roles.mdx
+3-3
Original file line number
Diff line number
Diff line change
@@ -3,12 +3,12 @@ title: "Project Level Roles for AWS"
3
3
---
4
4
5
5
Multi-account setups are pretty common. In many cases you want to use a different account for
6
-
different sets of projects. If you wish to acheive this outside of digger and only use profile names and set
6
+
different sets of projects. If you wish to achieve this outside of digger and only use profile names and set
7
7
them directly in terraform you can use this as an [example repository](https://github.com/diggerhq/demo-assume-role-multi-account-aws)
8
8
9
9
You can also use digger.yml to specify which roles should be used for which repository. In this case you specify a main
10
10
role in the workflow file using `aws-role-to-assume` (or using keys) and inside the repo if you wish to assume
11
-
a differnt role for a specific project you specify an `aws_role_to_assume` under that project.
11
+
a different role for a specific project you specify an `aws_role_to_assume` under that project.
12
12
If you only specify one role (either `state` or `command`) it is assumed that both options are the same role.
13
13
14
14
Example digger.yml:
@@ -27,7 +27,7 @@ projects:
27
27
command: "arn:/blabla/accid/prodaccount"
28
28
```
29
29
30
-
Using a workflow file as usual. Here is an [example repository](https://github.com/diggerhq/demo-assume-role-multi-account-aws_diggeryml) using digger.yml to assume differnt roles for differnt projects.
30
+
Using a workflow file as usual. Here is an [example repository](https://github.com/diggerhq/demo-assume-role-multi-account-aws_diggeryml) using digger.yml to assume different roles for different projects.
31
31
32
32
<Note>
33
33
NOTE: for locking to be configured user needs to also pass aws-role-to-assume in the workflow file as a
Copy file name to clipboardExpand all lines: docs/ce/howto/using-infracost.mdx
+1-1
Original file line number
Diff line number
Diff line change
@@ -45,7 +45,7 @@ After the pipeline run finishes, you should see Infracost breakdown output appen
45
45
46
46
## Diff
47
47
48
-
For `infracost diff` we'd need to run Infracost twice: first to generate the breakdown on the main branch, then to generate diff on the PR branch. To help with that, Digger provides additional environment varialbes like `$PROJECT_NAME` and `$PR_BRANCH` (see [custom commands](/ce/howto/custom-commands)). You can then configure your workflow in digger.yml to switch branch to main, generate base breakdown, switch back to PR branch, generate diff and finally show it via `$DIGGER_OUT`, like below:
48
+
For `infracost diff` we'd need to run Infracost twice: first to generate the breakdown on the main branch, then to generate diff on the PR branch. To help with that, Digger provides additional environment variables like `$PROJECT_NAME` and `$PR_BRANCH` (see [custom commands](/ce/howto/custom-commands)). You can then configure your workflow in digger.yml to switch branch to main, generate base breakdown, switch back to PR branch, generate diff and finally show it via `$DIGGER_OUT`, like below:
Copy file name to clipboardExpand all lines: docs/ce/howto/using-terragrunt.mdx
+2-2
Original file line number
Diff line number
Diff line change
@@ -25,8 +25,8 @@ This will perform a `terragrunt apply` after changes are detected within this di
25
25
# Dynamically generating Terragrunt projects
26
26
27
27
<Note>
28
-
This is not the prefered way of generating terragrunt projects and we advise you to instead use the [blocks declarative](/ce/howto/generate-projects#blocks-syntax-with-terragrunt)
29
-
since this way may be depracated in the future
28
+
This is not the preferred way of generating terragrunt projects and we advise you to instead use the [blocks declarative](/ce/howto/generate-projects#blocks-syntax-with-terragrunt)
Copy file name to clipboardExpand all lines: docs/ee/gitlab-support.mdx
+2-2
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ You can use digger with gitlab as your VCS and gitlab pipelines as a CI backend.
9
9
10
10
- Having a valid digger EE license key. If you don't have a license key please [contact us](https://calendly.com/diggerdev/diggerdemo) to request an EE trial
11
11
- A gitlab account.
12
-
- a personal github access token. This can be created from user prefences > access tokens
12
+
- a personal github access token. This can be created from user preferences > access tokens
0 commit comments