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
Config file is where the variables affecting the behaviour of notabot are defined.
3
+
A repository configuration file specifies how notifications should be handled for a given repository. It should be at the root of your monorepo in the main branch. The bot will look for a `notabot.json` file by default, but you can change this behavior with the `--config` flag.
4
+
5
+
When the bot receives its first incoming GitHub notification, it will query the repository URL to retrieve its configuration file. For subsequent notifications, it will use the cached configuration unless an update is detected.
6
+
7
+
To update the configuration, simply edit the configuration file and push your changes to GitHub. The bot will detect and apply those changes to the configuration, and will be reflected in the next request onwards.
8
+
9
+
Refer [here](https://docs.github.com/en/free-pro-team@latest/developers/webhooks-and-events/webhook-events-and-payloads) for more information on GitHub event payload structure.
4
10
5
11
# Configuration values
6
12
7
13
**example**
8
14
```json
9
15
{
10
-
"offline": "github-api-cache",
11
16
"main_branch_name": "develop",
12
17
"status_rules": {
13
18
...
@@ -17,16 +22,13 @@ Config file is where the variables affecting the behaviour of notabot are define
17
22
},
18
23
"label_rules": {
19
24
...
20
-
},
21
-
"suppress_cancelled_events": true
25
+
}
22
26
}
23
27
```
24
28
25
29
| value | description | optional | default |
26
30
|-|-|-|-|
27
31
|`main_branch_name`| main branch used for the repo; filtering notifications about merges of main into other branches | Yes | - |
28
-
|`offline`| path to github api data when http calls are not allowed; used for testing | Yes | - |
29
-
|`suppress_cancelled_events`| supresses status cancelled events | Yes |`true`|
30
32
|`status_rules`| status rules config object | No | - |
31
33
|`label_rules`| label rules config object | No | - |
32
34
|`prefix_rules`| prefix rules config object | No | - |
@@ -68,38 +70,28 @@ A json object with fields of bools for each status type.
68
70
|`cancelled`| provide regex to ignore `failure` notifications with a description that matches it | Yes | - |
69
71
70
72
71
-
## Label Config
73
+
## Label Options
72
74
73
-
Label rules apply to PR and issues notifications.
75
+
**Label rules** apply to PR and issue notifications. If a payload matches multiple rules, they are all included.
74
76
75
-
**example**
77
+
**Example**
76
78
```json
77
79
"label_rules": {
78
80
"default_channel": "default",
79
81
"rules": [
80
82
{
81
-
"allow": [
82
-
"backend"
83
-
],
84
-
"ignore": [],
83
+
"allow": ["backend"],
85
84
"channel": "backend"
86
85
},
87
86
{
88
-
"allow": [
89
-
"a1"
90
-
],
91
-
"ignore": [],
87
+
"allow": ["a1"],
92
88
"channel": "a1-bot"
93
89
},
94
90
{
95
-
"allow": [
96
-
"a3"
97
-
],
98
-
"ignore": [],
91
+
"allow": ["a3"],
99
92
"channel": "a3"
100
93
},
101
94
{
102
-
"allow": [],
103
95
"ignore": [
104
96
"backend",
105
97
"a1",
@@ -113,57 +105,52 @@ Label rules apply to PR and issues notifications.
113
105
114
106
| value | description | optional | default |
115
107
|-|-|-|-|
116
-
|`default_channel`| default channel to notify if no rules match | Yes |no channels will be notified on default|
108
+
|`default_channel`| default channel to notify if no rules match | Yes |None|
117
109
|`rules`| list of `label_rule` objects | No | - |
118
110
119
111
### Label Rule
120
112
113
+
A **label rule** specifies whether or not a Slack channel should be notified, based on the labels present in the given payload. For each rule, `ignore` is a blacklist of labels that should not notify the rule's channel, and `allow` is a whitelist of labels that should. The `ignore` list takes precedence over the `allow` list. Both are optional; if neither are provided, the rule will always generate a notification for its channel.
114
+
121
115
| value | description | optional | default |
122
116
|-|-|-|-|
123
-
|`allow`| whitelist of label values that match this rule; if list is empty it vacuously satisfies the rule | No | - |
124
-
|`ignore`| blacklist of label values; any labels matching will not match the rule | No | - |
125
-
|`channel`| channel to use as webhook if matching this label rule | No | - |
126
-
127
-
## Prefix Config
117
+
|`allow`| whitelist of label values; if not provided, the rule is vacuously satisfied | Yes | - |
118
+
|`ignore`| blacklist of label values; any labels matching will not match the rule | Yes | - |
119
+
|`channel`| channel to use as webhook if the rule is matched | No | - |
128
120
129
-
Prefix rules apply to filenames. If a filename satisfies a prefix rule, the rule's channel will be notified.
121
+
## Prefix Options
130
122
131
-
The prefix config object is exactly the same as **Label Config** except its `rules` are list of `prefix_rule` objects.
123
+
**Prefix rules** apply to push, commit comment, and status notifications. If a filename satisfies a prefix rule, the rule's channel will be notified. If a filename matches multiple rules, only the one that is matched by the *longest prefix* is included.
132
124
133
-
**example**
125
+
**Example**
134
126
```json
135
127
"prefix_rules": {
136
128
"default_channel": "default",
137
129
"rules": [
138
130
{
139
-
"allow": [
140
-
"backend/a1"
141
-
],
142
-
"ignore": [],
131
+
"allow": ["backend/a1"],
143
132
"channel": "a1"
144
133
},
145
134
{
146
135
"allow": [
147
136
"backend/a5",
148
137
"backend/a4"
149
138
],
150
-
"ignore": [],
151
139
"channel": "backend"
152
140
},
153
141
{
154
-
"allow": [],
155
-
"ignore": [],
156
142
"channel": "all-push-events"
157
143
}
158
144
]
159
145
},
160
146
```
161
147
162
-
163
148
### Prefix Rule
164
149
150
+
A **prefix rule** specifies whether or not a Slack channel should be notified, based on the filenames present in the commits associated with the given payload. The semantics for the `allow` and `ignore` fields are the same as those for label rules (see above).
151
+
165
152
| value | description | optional | default |
166
153
|-|-|-|-|
167
-
|`allow`| whitelist of strings that if prefixed in the filename matches the rule |No| - |
168
-
|`ignore`| blacklist of strings that if prefixed in the filename does not match the rule |No| - |
169
-
|`channel`| channel to use as webhook if matching this prefix rule| No | - |
154
+
|`allow`| whitelist of file prefixes that match the rule |Yes| - |
155
+
|`ignore`| blacklist of file prefixes that do not match the rule |Yes| - |
156
+
|`channel`| channel to use as webhook if the rule is matched| No | - |
Secret file is where sensitive information such as the urls used for webhooks and other tokens are stored.
3
+
A secrets file stores sensitive information. Unlike the repository configuration file, it should not be checked into the monorepo's version control. Instead, store it locally at a location accessible by the bot.
4
4
5
-
# Secret Values
5
+
# Options
6
+
7
+
**Example**
6
8
7
-
**example**
8
9
```json
9
10
{
10
11
"slack_hooks": [
@@ -42,36 +43,14 @@ Secret file is where sensitive information such as the urls used for webhooks an
42
43
43
44
| value | description | optional | default |
44
45
|-|-|-|-|
45
-
|`slack_hooks`| list of webhook config objects| No | - |
46
+
|`slack_hooks`| list of channel names (`channel`) and their corresponding webhook endpoint (`url`)| No | - |
46
47
|`gh_token`| specify to grant the bot access to private repositories; omit for public repositories | Yes | - |
47
-
|`gh_hook_token`| specify to ensure the bot only receives GitHub notifications from pre-approved repositories | Yes | - |
48
+
|`gh_webhook_secret`| specify to ensure the bot only receives GitHub notifications from pre-approved repositories | Yes | - |
48
49
49
50
## `gh_token`
50
51
51
-
### Token generation
52
-
53
-
Some event notifications (e.g., status, commit comment) require a personal token to be addded to the configuration. To create a personal token, take the following steps:
54
-
1. Verify your email address, if needed.
55
-
1. In the upper-right corner of any page, click your profile photo, then click **Settings**.
56
-
1. In the left sidebar, click **Developer settings**.
57
-
1. In the left sidebar, click **Personal access tokens**.
58
-
1. Click **Generate new token**.
59
-
1. Give your token a descriptive name in the **Note** section.
60
-
1. Grant ***repo*** scope.
61
-
1. Click **Generate token**.
62
-
1. Copy the token to `secrets.json` file in a `gh_token` field.
63
-
64
-
For more detailed instructions on token generation, refer to https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line.
65
-
52
+
Some operations, such as fetching a config file from a private repository, or the commit corresponding to a commit comment event, require a personal access token. Refer [here](https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/creating-a-personal-access-token) for detailed instructions on token generation.
66
53
67
-
## `gh_hook_token`
68
-
For more information on `gh_hook_token` see [developer.github.com/webhooks/securing](https://developer.github.com/webhooks/securing/)
54
+
## `gh_webhook_secret`
69
55
70
-
## Webhook Config
71
-
72
-
Channels that are defined in rules in config will be mapped to urls defined in the webhook
73
-
74
-
| value | description | optional | default |
75
-
|-|-|-|-|
76
-
|`url`| url to call to send the message | No | - |
77
-
|`channel`| name of the channel where the message will be posted as used in config | No | - |
56
+
Refer [here](https://docs.github.com/en/free-pro-team@latest/developers/webhooks-and-events/securing-your-webhooks) for more information on securing webhooks with a token.
0 commit comments