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/integrations/github.md
+6-2Lines changed: 6 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -113,6 +113,7 @@ In this example we configured the merge method to be `squash`. See [Bot Configur
113
113
114
114
One way to signal to SQLMesh that a PR is ready to go to production is through the use of "Required Approvers".
115
115
In this approach users configure their SQLMesh project to list users that are designated as "Required Approver" and then when the bot detects an approval was received from one of these individuals then it determines that it is time to deploy to production.
116
+
The bot will only do the deploy to prod if the base branch is a production branch (as defined in the bot's configuration but defaults to either `main` or `master`).
116
117
This pattern can be a great fit for teams that already have an approval process like this in place and therefore it actually removes an extra step from either the author or the approver since SQLMesh will automate the deployment and merge until of it having to be manually done.
117
118
118
119
##### Required Approval Configuration
@@ -295,8 +296,9 @@ Below is an example of how to define the default config for the bot in either YA
295
296
| `default_pr_start` | Default start when creating PR environment plans. If running in a mode where the bot automatically backfills models (based on `auto_categorize_changes` behavior) then this can be used to limit the amount of data backfilled. Defaults to `None` meaning the start date is set to the earliest model's start or to 1 day ago if [data previews](../concepts/plans.md#data-preview) need to be computed. | str | N |
296
297
| `skip_pr_backfill` | Indicates if the bot should skip backfilling models in the PR environment. Default: `True`| bool | N |
297
298
| `pr_include_unmodified` | Indicates whether to include unmodified models in the PR environment. Default to the project's config value (which defaults to `False`) | bool | N |
298
-
| `run_on_deploy_to_prod` | Indicates whether to run latest intervals when deploying to prod. If set to false, the deployment will backfill only the changed models up to the existing latest interval in production, ignoring any missing intervals beyond this point. Default: `False`| bool | N |
299
-
| `pr_environment_name` | The name of the PR environment to create for which a PR number will be appended to. Defaults to the repo name if not provided. Note: The name will be normalized to alphanumeric + underscore and lowercase. | str | N |
299
+
| `run_on_deploy_to_prod` | Indicates whether to run latest intervals when deploying to prod. If set to false, the deployment will backfill only the changed models up to the existing latest interval in production, ignoring any missing intervals beyond this point. Default: `False`| bool | N |
300
+
| `pr_environment_name` | The name of the PR environment to create for which a PR number will be appended to. Defaults to the repo name if not provided. Note: The name will be normalized to alphanumeric + underscore and lowercase. | str | N |
301
+
| `prod_branch_name` | The name of the git branch associated with production. Ex: "prod". Default: "main" or "master" is considered prod | str | N |
300
302
301
303
Example with all properties defined:
302
304
@@ -317,6 +319,7 @@ Example with all properties defined:
317
319
default_pr_start: "1 week ago"
318
320
skip_pr_backfill: false
319
321
run_on_deploy_to_prod: false
322
+
prod_branch_name: production
320
323
```
321
324
322
325
=== "Python"
@@ -340,6 +343,7 @@ Example with all properties defined:
PR with a non-breaking change and auto-categorization will be backfilled, but NOT automatically merged or deployed to production if it is branched from a non-production branch.
1965
+
1966
+
Scenario:
1967
+
- PR is not merged
1968
+
- PR has been approved by a required reviewer
1969
+
- Tests passed
1970
+
- PR Merge Method defined
1971
+
- Delete environment is disabled
1972
+
- Changes made in PR with auto-categorization
1973
+
- PR is not merged, despite having required approval, since the base branch is not prod
0 commit comments