Skip to content

Commit d36690e

Browse files
committed
adding docs
1 parent 795ae02 commit d36690e

File tree

5 files changed

+51
-1
lines changed

5 files changed

+51
-1
lines changed

README.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -301,7 +301,7 @@ As seen above, we have two steps. One for a noop deploy, and one for a regular d
301301
| `enforced_deployment_order` | `false` | `""` | A comma separated list of environments that must be deployed in a specific order. Example: `"development,staging,production"`. If this is set then you cannot deploy to latter environments unless the former ones have a successful and active deployment on the latest commit first - See the [enforced deployment order docs](./docs/enforced-deployment-order.md) for more details |
302302
| `use_security_warnings` | `false` | `"true"` | Whether or not to leave security related warnings in log messages during deployments. Default is `"true"` |
303303
| `allow_non_default_target_branch_deployments` | `false` | `"false"` | Whether or not to allow deployments of pull requests that target a branch other than the default branch (aka stable branch) as their merge target. By default, this Action would reject the deployment of a branch named `feature-branch` if it was targeting `foo` instead of `main` (or whatever your default branch is). This option allows you to override that behavior and be able to deploy any branch in your repository regardless of the target branch. This option is potentially unsafe and should be used with caution as most default branches contain branch protection rules. Often times non-default branches do not contain these same branch protection rules. Follow along in this [issue thread](https://github.com/github/branch-deploy/issues/340) to learn more. |
304-
| `deployment_confirmation` | `false` | `"false"` | Whether or not to require an additional confirmation before a deployment can continue. Default is `"false"`. If your project requires elevated security, it is highly recommended to enable this option - especially in open source projects where you might be deploying forks. |
304+
| `deployment_confirmation` | `false` | `"false"` | Whether or not to require an additional confirmation before a deployment can continue. Default is `"false"`. If your project requires elevated security, it is highly recommended to enable this option - especially in open source projects where you might be deploying forks - [Deployment confirmation docs](./docs/deployment-confirmation.md) |
305305
| `deployment_confirmation_timeout` | `false` | `60` | The number of seconds to wait for a deployment confirmation before timing out. Default is `60` seconds (1 minute). |
306306

307307
## Outputs 📤
406 KB
Loading
200 KB
Loading

docs/assets/deployment-timeout.png

271 KB
Loading

docs/deployment-confirmation.md

Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
# Deployment Confirmation
2+
3+
## Overview
4+
5+
For projects that require the highest level of deployment safety/security, the branch-deploy Action can be configured to require a deployment confirmation before a deployment is allowed to proceed.
6+
7+
This can be considered a "final safety check" before a deployment is allowed to proceed.
8+
9+
By using this feature, it is also an extremely effect way to prevent accidental or malicious commits from being deployed without first having one last safety review. This is important for hardening against Actions related [TOCTOU](https://github.com/AdnaneKhan/ActionsTOCTOU) vulnerabilities.
10+
11+
## How it works
12+
13+
When a user invokes a deployment via the `.deploy` (or `.noop`) command, the branch-deploy Action will pause _just_ before the final call to start a deployment by this Action. The Action will then create a new comment on the pull request that invoked the deployment, asking the user to confirm (or reject) the deployment.
14+
15+
This comment will provide the user with a summary of the deployment that is __about__ to be run. The user will then have the opportunity to confirm (with a 👍) or deny (with a 👎) the deployment.
16+
17+
Depending on the user's response (or lack of response), the branch-deploy Action will update the comment with the outcome.
18+
19+
### Usage
20+
21+
```yaml
22+
- uses: github/branch-deploy@vX.X.X
23+
id: branch-deploy
24+
with:
25+
trigger: ".deploy"
26+
deployment_confirmation: true # <-- enables deployment confirmation
27+
deployment_confirmation_timeout: 60 # <-- sets the timeout to 60 seconds
28+
```
29+
30+
### Confirming a Deployment 👍
31+
32+
If the user confirms the deployment, the deployment will proceed as normal:
33+
34+
![confirm](./assets/deployment-approved.png)
35+
36+
### Rejecting a Deployment 👎
37+
38+
If the user rejects the deployment, the branch-deploy Action will immediately exit and the `continue` output will not be set to `true`. This will prevent the deployment from proceeding.
39+
40+
![reject](./assets/deployment-rejected.png)
41+
42+
### Timing Out 🕒
43+
44+
If the user does not respond within a set amount of time (configurable, but defaults to 1 minute), the deployment will be automatically rejected. The user will be notified of this outcome.
45+
46+
![timeout](./assets/deployment-timeout.png)
47+
48+
## Demo 📹
49+
50+
View a [demo video](https://github.com/github/branch-deploy/pull/374) of a deployment confirmation in action on the original pull request that introduced this feature.

0 commit comments

Comments
 (0)