generated from actions/typescript-action
-
Notifications
You must be signed in to change notification settings - Fork 47
/
action.yml
270 lines (270 loc) · 18.2 KB
/
action.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
name: "branch-deploy"
description: "Enabling Branch Deployments through IssueOps with GitHub Actions"
author: "Grant Birkinbine"
branding:
icon: 'git-branch'
color: 'gray-dark'
inputs:
github_token:
description: The GitHub token used to create an authenticated client - Provided for you by default!
default: ${{ github.token }}
required: true
status:
description: The status of the GitHub Actions - For use in the post run workflow - Provided for you by default!
default: ${{ job.status }}
required: true
environment:
description: 'The name of the default environment to deploy to. Example: by default, if you type `.deploy`, it will assume "production" as the default environment'
required: false
default: "production"
environment_targets:
description: 'Optional (or additional) target environments to select for use with deployments. Example, "production,development,staging". Example usage: `.deploy to development`, `.deploy to production`, `.deploy to staging`'
required: false
default: "production,development,staging"
draft_permitted_targets:
description: 'Optional environments which can allow "draft" pull requests to be deployed. By default, this input option is empty and no environments allow deployments sourced from a pull request in a "draft" state. Examples: "development,staging"'
required: false
default: ""
environment_urls:
description: 'Optional target environment URLs to use with deployments. This input option is a mapping of environment names to URLs and the environment names must match the "environment_targets" input option. This option is a comma separated list with pipes (|) separating the environment from the URL. Note: "disabled" is a special keyword to disable an environment url if you enable this option. Format: "<environment1>|<url1>,<environment2>|<url2>,etc" Example: "production|https://myapp.com,development|https://dev.myapp.com,staging|disabled"'
required: false
default: ""
environment_url_in_comment:
description: 'If the environment_url detected in the deployment should be appended to the successful deployment comment or not. Examples: "true" or "false"'
required: false
default: "true"
production_environments:
description: 'A comma separated list of environments that should be treated as "production". GitHub defines "production" as an environment that end users or systems interact with. Example: "production,production-eu". By default, GitHub will set the "production_environment" to "true" if the environment name is "production". This option allows you to override that behavior so you can use "prod", "prd", "main", "production-eu", etc. as your production environment name. ref: https://github.com/github/branch-deploy/issues/208'
required: false
default: "production"
reaction:
description: 'If set, the specified emoji "reaction" is put on the comment to indicate that the trigger was detected. For example, "rocket" or "eyes"'
required: false
default: "eyes"
trigger:
description: 'The string to look for in comments as an IssueOps trigger. Example: ".deploy"'
required: false
default: ".deploy"
noop_trigger:
description: 'The string to look for in comments as an IssueOps noop trigger. Example: ".noop"'
required: false
default: ".noop"
lock_trigger:
description: 'The string to look for in comments as an IssueOps lock trigger. Used for locking branch deployments on a specific branch. Example: ".lock"'
required: false
default: ".lock"
unlock_trigger:
description: 'The string to look for in comments as an IssueOps unlock trigger. Used for unlocking branch deployments. Example: ".unlock"'
required: false
default: ".unlock"
help_trigger:
description: 'The string to look for in comments as an IssueOps help trigger. Example: ".help"'
required: false
default: ".help"
lock_info_alias:
description: 'An alias or shortcut to get details about the current lock (if it exists) Example: ".info"'
required: false
default: ".wcid"
permissions:
description: 'The allowed GitHub permissions an actor can have to invoke IssueOps commands - Example: "write,maintain,admin"'
required: true
default: "write,maintain,admin"
commit_verification:
description: 'Whether or not to enforce commit verification before a deployment can continue. Default is "false"'
required: false
default: "false"
param_separator:
description: 'The separator to use for parsing parameters in comments in deployment requests. Parameters will are saved as outputs and can be used in subsequent steps'
required: false
default: "|"
global_lock_flag:
description: 'The flag to pass into the lock command to lock all environments. Example: "--global"'
required: false
default: "--global"
stable_branch:
description: 'The name of a stable branch to deploy to (rollbacks). Example: "main"'
required: false
default: "main"
update_branch:
description: 'Determine how you want this Action to handle "out-of-date" branches. Available options: "disabled", "warn", "force". "disabled" means that the Action will not care if a branch is out-of-date. "warn" means that the Action will warn the user that a branch is out-of-date and exit without deploying. "force" means that the Action will force update the branch. Note: The "force" option is not recommended due to Actions not being able to re-run CI on commits originating from Actions itself'
required: false
default: "warn"
outdated_mode:
description: 'The mode to use for determining if a branch is up-to-date or not before allowing deployments. This option is closely related to the "update_branch" input option above. There are three available modes to choose from "pr_base", "default_branch", or "strict". The default is "strict" to help ensure that deployments are using the most up-to-date code. Please see the docs/outdated_mode.md document for more details.'
required: false
default: "strict"
required_contexts:
description: 'Manually enforce commit status checks before a deployment can continue. Only use this option if you wish to manually override the settings you have configured for your branch protection settings for your GitHub repository. Default is "false" - Example value: "context1,context2,context3" - In most cases you will not need to touch this option'
required: false
default: "false"
skip_ci:
description: 'A comma separated list of environments that will not use passing CI as a requirement for deployment. Use this option to explicitly bypass branch protection settings for a certain environment in your repository. Default is an empty string "" - Example: "development,staging"'
required: false
default: ""
checks:
description: 'This input defines how the branch-deploy Action will handle the status of CI checks on your PR/branch before deployments can continue. `"all"` requires that all CI checks must pass in order for a deployment to be triggered. `"required"` only waits for required CI checks to be passing. You can also pass in the names of your CI jobs in a comma separated list. View the documentation (docs/checks.md) for more details.'
required: false
default: "all"
ignored_checks:
description: 'A comma separated list of checks that will be ignored when determining if a deployment can continue. This setting allows you to skip failing, pending, or incomplete checks regardless of the `checks` setting above. Example: "lint,markdown-formatting,update-pr-label". View the documentation (docs/checks.md) for more details.'
required: false
default: ""
skip_reviews:
description: 'A comma separated list of environment that will not use reviews/approvals as a requirement for deployment. Use this options to explicitly bypass branch protection settings for a certain environment in your repository. Default is an empty string "" - Example: "development,staging"'
required: false
default: ""
allow_forks:
description: 'Allow branch deployments to run on repository forks. If you want to harden your workflows, this option can be set to false. Default is "true"'
required: false
default: "true"
admins:
description: 'A comma separated list of GitHub usernames or teams that should be considered admins by this Action. Admins can deploy pull requests without the need for branch protection approvals. Example: "monalisa,octocat,my-org/my-team"'
required: false
default: "false"
admins_pat:
description: 'A GitHub personal access token with "read:org" scopes. This is only needed if you are using the "admins" option with a GitHub org team. For example: "my-org/my-team"'
required: false
default: "false"
merge_deploy_mode:
description: This is an advanced option that is an alternate workflow bundled into this Action. You can control how merge commits are handled when a PR is merged into your repository's default branch. If the merge commit SHA matches the latest deployment for the same environment, then the 'continue' output will be set to 'false' which indicates that a deployment should not be performed again as the latest deployment is identical. If the merge commit SHA does not match the latest deployment for the same environment, then the 'continue' output will be set to 'true' which indicates that a deployment should be performed. With this option, the 'environment' output is also set for subsequent steps to reference
required: false
default: "false"
unlock_on_merge_mode:
description: This is an advanced option that is an alternate workflow bundled into this Action. You can optionally use this mode in a custom workflow to automatically release all locks that came from a pull request when the pull request is merged. This is useful if you want to ensure that locks are not left behind when a pull request is merged.
required: false
default: "false"
skip_completing:
description: 'If set to "true", skip the process of completing a deployment. You must manually create a deployment status after the deployment is complete. Default is "false"'
required: false
default: "false"
deploy_message_path:
description: 'The path to a markdown file which is used as a template for custom deployment messages. Example: ".github/deployment_message.md"'
required: false
default: ".github/deployment_message.md"
sticky_locks:
description: 'If set to "true", locks will not be released after a deployment run completes. This applies to both successful, and failed deployments.Sticky locks are also known as "hubot style deployment locks". They will persist until they are manually released by a user, or if you configure another workflow with the "unlock on merge" mode to remove them automatically on PR merge.'
required: false
default: "false"
sticky_locks_for_noop:
description: 'If set to "true", then sticky_locks will also be used for noop deployments. This can be useful in some cases but it often leads to locks being left behind when users test noop deployments.'
required: false
default: "false"
allow_sha_deployments:
description: 'If set to "true", then you can deploy a specific sha instead of a branch. Example: ".deploy 1234567890abcdef1234567890abcdef12345678 to production" - This is dangerous and potentially unsafe, view the docs to learn more: https://github.com/github/branch-deploy/blob/main/docs/sha-deployments.md'
required: false
default: "false"
disable_naked_commands:
description: 'If set to "true", then naked commands will be disabled. Example: ".deploy" will not trigger a deployment. Instead, you must use ".deploy to production" to trigger a deployment. This is useful if you want to prevent accidental deployments from happening. Read more about naked commands here: https://github.com/github/branch-deploy/blob/main/docs/naked-commands.md'
required: false
default: "false"
successful_deploy_labels:
description: 'A comma separated list of labels to add to the pull request when a deployment is successful. Example: "deployed,success"'
required: false
default: ""
successful_noop_labels:
description: 'A comma separated list of labels to add to the pull request when a noop deployment is successful. Example: "noop,success"'
required: false
default: ""
failed_deploy_labels:
description: 'A comma separated list of labels to add to the pull request when a deployment fails. Example: "failed,deploy-failed"'
required: false
default: ""
failed_noop_labels:
description: 'A comma separated list of labels to add to the pull request when a noop deployment fails. Example: "failed,noop-failed"'
required: false
default: ""
skip_successful_noop_labels_if_approved:
description: 'Whether or not the post run logic should skip adding successful noop labels if the pull request is approved. This can be useful if you add a label such as "ready-for-review" after a .noop completes but want to skip adding that label in situations where the pull request is already approved.'
required: false
default: "false"
skip_successful_deploy_labels_if_approved:
description: 'Whether or not the post run logic should skip adding successful deploy labels if the pull request is approved. This can be useful if you add a label such as "ready-for-review" after a .deploy completes but want to skip adding that label in situations where the pull request is already approved.'
required: false
default: "false"
enforced_deployment_order:
description: '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.'
required: false
default: ""
use_security_warnings:
description: 'Whether or not to leave security related warnings in log messages during deployments. Default is "true"'
required: false
default: "true"
outputs:
continue:
description: 'The string "true" if the deployment should continue, otherwise empty - Use this to conditionally control if your deployment should proceed or not'
triggered:
description: 'The string "true" if the trigger was found, otherwise the string "false"'
comment_body:
description: The comment body
issue_number:
description: The issue number of the pull request (or issue) that was commented on
actor:
description: The GitHub handle of the actor that invoked the IssueOps command
environment:
description: The environment that has been selected for a deployment
params:
description: The raw parameters that were passed into the deployment command (see param_separator)
parsed_params:
description: A stringified JSON object of the parsed parameters that were passed into the deployment command
noop:
description: 'The string "true" if the noop trigger was found, otherwise the string "false" - Use this to conditionally control whether your deployment runs as a noop or not'
sha:
description: The sha of the branch to be deployed
default_branch_tree_sha:
description: The sha of the default branch tree (useful for subsequent workflow steps if they need to do commit comparisons)
base_ref:
description: The base ref that the pull request is merging into
ref:
description: The ref (branch or sha) to use with deployment
comment_id:
description: The comment id which triggered this deployment
type:
description: "The type of trigger that was detected (examples: deploy, lock, unlock, lock-info-alias, help)"
fork:
description: 'The string "true" if the pull request is a fork, otherwise "false"'
fork_ref:
description: 'The true ref of the fork'
fork_label:
description: 'The API label field returned for the fork'
fork_checkout:
description: 'The console command presented in the GitHub UI to checkout a given fork locally'
fork_full_name:
description: 'The full name of the fork in "org/repo" format'
deployment_id:
description: The ID of the deployment created by running this action
environment_url:
description: The environment URL detected and used for the deployment (sourced from the environment_urls input)
initial_reaction_id:
description: The reaction id for the initial reaction on the trigger comment
initial_comment_id:
description: The comment id for the "Deployment Triggered 🚀" comment created by the action
actor_handle:
description: The handle of the user who triggered the action
global_lock_claimed:
description: 'The string "true" if the global lock was claimed'
global_lock_released:
description: 'The string "true" if the global lock was released'
unlocked_environments:
description: 'Only exposed when using the "unlock on merge" mode - This output variable will contain a comma separated list of the environments that were unlocked'
sha_deployment:
description: 'If "allow_sha_deployments" is enabled, and a sha deployment is performed instead of a branch deployment, this output variable will contain the sha that was deployed. Otherwise, this output variable will be empty'
review_decision:
description: 'The pull request review status. Can be one of a few values - examples: APPROVED, REVIEW_REQUIRED, CHANGES_REQUESTED, skip_reviews,, null'
is_outdated:
description: 'The string "true" if the branch is outdated, otherwise "false"'
merge_state_status:
description: 'The status of the merge state. Can be one of a few values - examples: "DIRTY", "DRAFT", "CLEAN", etc'
commit_status:
description: 'The status of the commit. Can be one of a few values - examples: "SUCCESS", null, "skip_ci", "PENDING", "FAILURE" etc'
approved_reviews_count:
description: 'The number of approved reviews on the pull request'
needs_to_be_deployed:
description: 'A comma separated list of environments that need successful and active deployments before the current environment (that was requested) can be deployed. This output is tied to the "enforced_deployment_order" input option.'
commit_verified:
description: 'The string "true" if the commit has a verified signature, otherwise "false"'
total_seconds:
description: 'The total number of seconds that the deployment took to complete (Integer)'
runs:
using: "node20"
main: "dist/index.js"
post: "dist/index.js"