|
2 | 2 | title: "Apply Requirements" |
3 | 3 | --- |
4 | 4 |
|
5 | | -Digger currently does not support `apply_requirements` (like in Atlantis). Coming soon - ([#1252](https://github.com/diggerhq/digger/issues/1252)) |
| 5 | +Digger supports apply_requirements on the project level to enforce certain conditions are met before an apply action occurs. |
6 | 6 |
|
7 | | -## Workaround |
| 7 | +The following apply conditions are supported: |
8 | 8 |
|
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 “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. |
| 9 | +``` |
| 10 | +projects: |
| 11 | + - name: dev |
| 12 | + dir: dev |
| 13 | + apply_requirements: [] |
| 14 | + - name: prod |
| 15 | + dir: prod |
| 16 | + apply_requirements: [mergeable, undiverged, approved] |
| 17 | +``` |
| 18 | + |
| 19 | +Digger supports *mergeable*, *undiverged* and *approved* conditions. The default value for apply_requirements is [mergeable] if not set. |
| 20 | +Here is an explanation of each: |
| 21 | + |
| 22 | +## Mergeable |
| 23 | + |
| 24 | +The mergeable requirement will prevent applies unless a pull request is able to be merged. |
| 25 | +In GitHub, if you're not using Protected Branches then all pull requests are mergeable unless there is a conflict. |
11 | 26 |
|
12 | | -Note: there is a [known issue](https://github.com/diggerhq/digger/issues/1180) that would |
13 | | - 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 |
14 | | - by setting the `skip_merge_check` flag as follows (we have to set the other configurations since they are currently required): |
| 27 | +<Note> |
| 28 | + There is a [known issue](https://github.com/diggerhq/digger/issues/1180) that would |
| 29 | + 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 |
| 30 | + by setting the `skip_merge_check` flag as follows (we have to set the other configurations since they are currently required): |
| 31 | + |
| 32 | +</Note> |
| 33 | + |
| 34 | +### Usage |
| 35 | + |
| 36 | +You can enable the mergeable requirement on the project level: |
15 | 37 |
|
16 | 38 | ``` |
17 | 39 | projects: |
18 | | -- name: dev |
19 | | - dir: dev |
20 | | - workflow: mydev |
| 40 | + - name: dev |
| 41 | + dir: dev |
| 42 | + apply_requirements: [mergeable] |
| 43 | +``` |
21 | 44 |
|
22 | | -workflows: |
23 | | - mydev: |
24 | | - workflow_configuration: |
25 | | - on_pull_request_pushed: ["digger plan"] |
26 | | - on_pull_request_closed: ["digger unlock"] |
27 | | - on_commit_to_default: ["digger unlock"] |
28 | | - skip_merge_check: true |
| 45 | +Note that it is set by default so it would be enforced even if you don't specify it. |
| 46 | + |
| 47 | +## Approved |
| 48 | +The approved requirement will prevent applies unless the pull request is approved by at least one person other than the author. |
| 49 | + |
| 50 | +### Usage |
| 51 | + |
| 52 | +You can enable the approved requirement on the project level: |
| 53 | + |
| 54 | +``` |
| 55 | +projects: |
| 56 | + - name: dev |
| 57 | + dir: dev |
| 58 | + apply_requirements: [approved] |
29 | 59 | ``` |
30 | 60 |
|
31 | | -## Requiring undiverged branches in PRs |
| 61 | +## Undiverged |
32 | 62 |
|
33 | 63 | While PR locks prevent you from PRs stepping on eachother in parallel, they still do not protect you from a stale branch |
34 | | -that is behind the current main head. In order to safeguard against this you have a few options: |
| 64 | +that is behind the current main head. The undiverged requirement helps enforce this by preventing applies if there are any changes on the base branch |
| 65 | +since the PR was opened. It can be resolved by merging main into the PR branch or rebasing the PR branch on top of main. In the case of github this is done by querying the comparecommits api on github side. |
35 | 66 |
|
36 | | -Force your repo to always have rebased branches from main. In github this is done by adding the branch protection rule: |
| 67 | +### Usage |
37 | 68 |
|
38 | | -Under settings > branch protection rules > Require branches to be up to date before merging → check this |
| 69 | +You can enable the undiverged requirement on the project level: |
39 | 70 |
|
40 | | -Since digger will always query github api for mergability status, this protects you from any stale apply from PRs being performed. |
| 71 | +``` |
| 72 | +projects: |
| 73 | + - name: dev |
| 74 | + dir: dev |
| 75 | + apply_requirements: [undiverged] |
| 76 | +``` |
41 | 77 |
|
42 | | - |
| 78 | +## Skipping mergeability check |
43 | 79 |
|
44 | | -Understandably this may not be feasible to mark especially for monorepos that mix code and terraform. In such cases you can achieve a similar effect by using a custom workflow like below (digger.yml): |
| 80 | +The default behaviour of digger is to perform a mergeability check before applying a PR. In order to skip the |
| 81 | +mergeability check you can specify an empty list of apply requirements on the project level |
45 | 82 |
|
46 | 83 | ``` |
47 | 84 | projects: |
48 | | -- name: gcp-infra |
49 | | - dir: cloud/terraform/gcp |
50 | | - workflow: terraform-strict |
| 85 | + - name: dev |
| 86 | + dir: dev |
| 87 | + apply_requirements: [] |
| 88 | +
|
| 89 | +Alternatively, you can also skip the mergeability check on the workflow level: |
51 | 90 |
|
52 | | -workflows: |
53 | | - terraform-strict: |
54 | | - plan: |
55 | | - steps: |
56 | | - - run: | |
57 | | - echo "Checking if branch is up-to-date with main..." |
58 | | - git fetch --unshallow origin main || git fetch origin main |
59 | | - git fetch --unshallow origin HEAD || git fetch origin HEAD |
60 | | - if ! git merge-base --is-ancestor origin/main HEAD; then |
61 | | - echo "❌ Branch is not up-to-date with main. Please rebase or merge main into your branch." |
62 | | - echo "Run: git fetch origin && git rebase origin/main" |
63 | | - exit 1 |
64 | | - fi |
65 | | - echo "✅ Branch is up-to-date with main" |
66 | | - - init |
67 | | - - plan |
68 | | - apply: |
69 | | - steps: |
70 | | - - run: | |
71 | | - echo "Checking if branch is up-to-date with main..." |
72 | | - git fetch --unshallow origin main || git fetch origin main |
73 | | - git fetch --unshallow origin HEAD || git fetch origin HEAD |
74 | | - if ! git merge-base --is-ancestor origin/main HEAD; then |
75 | | - echo "❌ Branch is not up-to-date with main. Please rebase or merge main into your branch." |
76 | | - echo "Run: git fetch origin && git rebase origin/main" |
77 | | - exit 1 |
78 | | - fi |
79 | | - echo "✅ Branch is up-to-date with main" |
80 | | - - init |
81 | | - - apply |
82 | 91 | ``` |
| 92 | +projects: |
| 93 | +- name: dev |
| 94 | + dir: dev |
| 95 | + workflow: mydev |
83 | 96 |
|
84 | | -We plan to eventually support this natively as a flag in digger |
| 97 | +workflows: |
| 98 | + mydev: |
| 99 | + workflow_configuration: |
| 100 | + on_pull_request_pushed: ["digger plan"] |
| 101 | + on_pull_request_closed: ["digger unlock"] |
| 102 | + on_commit_to_default: ["digger unlock"] |
| 103 | + skip_merge_check: true |
| 104 | +``` |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?v=4&size=40){kind=avatar}
0 commit comments