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
GitHub Actions help you automate tasks to run an actual deployment. GitHub Actions are event-driven, meaning that you can run a series of commands after a deployment event has occurred.
9
+
As described in the '[How it works](../concepts/how-it-work.md)' document, two preparations are required to connect with the deployment API; 1) Make sure your deployment tooling is listening for the Github [deployment](https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#deployment) event. 2) Update the deployment status by [API](https://docs.github.com/en/rest/reference/deployments#create-a-deployment-status) after execution is complete. This document will show how you can connect with the mainstream deployment tools.
10
10
11
-
To listening the deployment event, you must specify `deployment` for the `on` field. And you can use the `if` conditional to run a job for the specific environment. Here is the example below.
11
+
### GitHub Action
12
+
13
+
#### Listening for an event
14
+
15
+
GitHub Action provides the `on` syntax to define the type of activity that will trigger a workflow run, and it supports the deployment event.
12
16
13
17
```yaml
14
-
# Listening the deployment event
15
18
on:
16
19
deployment
20
+
```
17
21
22
+
And you can use the `if` conditional to run a job when an environment is met. You can use context to access the deployment environment.
The third-party plugin, [chrnorm/deployment-status](https://github.com/chrnorm/deployment-status), provides that a GitHub action updates the status of deployments as part of your GitHub CI workflows.
You can reference this [example](https://github.com/gitploy-io/gitploy/discussions/178) for integrating with GitHub action.
53
+
54
+
### Drone CI
55
+
56
+
#### Listening for an event
57
+
58
+
Drone CI provides the `trigger` field to limit pipeline execution based on the drone event type, supporting the `promote` event.
59
+
60
+
```yaml
61
+
trigger:
62
+
event:
63
+
- promote
64
+
```
65
+
66
+
And you can access the [`DRONE_DEPLOY_TO`](https://docs.drone.io/pipeline/environment/reference/drone-deploy-to/) environment by the environment if you need the conditional step.
67
+
68
+
#### Update the deployment status
69
+
70
+
The third-party plugin, [cedrichopf/drone-status](https://github.com/cedrichopf/drone-status), provides that a Drone CI updates the status of deployments as part of your CI pipelines.
71
+
72
+
```yaml
73
+
steps:
74
+
- name: Update the deployment status
75
+
image: cedrichopf/drone-status
76
+
settings:
77
+
api_token:
78
+
from_secret: GITHUB_TOKEN
79
+
context: deploy
80
+
state: success
81
+
description: Finish to deploy successfully.
82
+
```
83
+
84
+
### Spinnaker
85
+
86
+
#### Listening for an event
87
+
88
+
The trigger type has to be the webhook type to listen to an event, and the constraints verify repository and environment to determine if triggered or not.
Spinnaker provides a simple way to add a custom stage to call API instead of extending through codes. Spinnaker can typically make API calls as part of a pipeline by adding a custom stage.
95
+
96
+
To create a custom webhook, we have to add the configuration to the `orca-local.yml` file, located in `$HOME/.hal/default/profiles`. And the custom stage has a few variables, `owner`, `repo`, `deployment_id`, `description`, and `state`, for updating the deployment status dynamically. You can set up the variables for your project.
description: The state can be one of "queued", "in_progress", "success", "failure"
139
+
```
140
+
141
+
</details>
142
+
143
+
You can reference the [spinnaker demo](https://github.com/gitploy-io/spinnaker-demo) for integrating with Spinnaker.
144
+
145
+
146
+
147
+
### Internal Deployment Tooling
148
+
149
+
GitHub provides a well-organized [document](https://docs.github.com/en/rest/guides/delivering-deployments) to guide to build an internal deployment tooling to deploy on your servers with the Deployment API.
150
+
151
+
## Notification
39
152
40
-
Slack integration provides notifications for events.
153
+
### Slack
41
154
42
-
### Step 1: Create App
155
+
#### Step 1: Create App
43
156
44
157
Firstly, we have to create [Slack App](https://api.slack.com/apps). You should click the Create App button and fill out inputs.
45
158
46
-
### Step 2: Configure Permissions
159
+
#### Step 2: Configure Permissions
47
160
48
161
After creating App, we move to the *OAuth & Permissions* page and set up *the redirect URLs* and *Bot Token scopes*on this page. Firstly, you should add a new redirect URL with the `GITPLOY_SERVER_PROTO://GITPLOY_SERVER_HOST/slack/signin` format; secondly, add `chat:write` scope into the Bot Token scopes.
To enable Slack integration, you have to set up these environments when you run the server: `GITPLOY_SLACK_CLIENT_ID`and `GITPLOY_SLACK_CLIENT_SECRET`. You can get these credentials from *App Credentials* section of *Basic Information* page.
0 commit comments