Query Parameters
The list of fields to update.
Body
type is the type of the webhook.
TYPE_UNSPECIFIED
, SLACK
, DISCORD
, TEAMS
, DINGTALK
, FEISHU
, WECOM
, LARK
title is the title of the webhook.
url is the url of the webhook, should be unique within the project.
name is the name of the webhook, generated by the server. format: projects/{project}/webhooks/{webhook}
if direct_message is set, the notification is sent directly to the persons and url will be ignored. IM integration setting should be set for this function to work.
notification_types is the list of activities types that the webhook is interested in. Bytebase will only send notifications to the webhook if the activity type is in the list. It should not be empty, and should be a subset of the following:
- TYPE_ISSUE_CREATED
- TYPE_ISSUE_STATUS_UPDATE
- TYPE_ISSUE_PIPELINE_STAGE_UPDATE
- TYPE_ISSUE_PIPELINE_TASK_STATUS_UPDATE
- TYPE_ISSUE_FIELD_UPDATE
- TYPE_ISSUE_COMMENT_CREATE
Response
OK
Force issue labels to be used when creating an issue.
Allow modifying statement after issue is created.
Enable auto resolve issue.
Enforce issue title created by user instead of generated by Bytebase.
Whether to automatically enable backup.
Whether to skip backup errors and continue the data migration.
Whether to enable the database tenant mode for PostgreSQL. If enabled, the issue will be created with the prepend "set role <db_owner>" statement.
Whether to allow the issue creator to self-approve the issue.
Execution retry policy for the task run.
The maximum number of databases to sample during CI data validation. Without specification, sampling is disabled, resulting in a full validation.
The maximum number of parallel tasks to run during the rollout.
Labels are key-value pairs that can be attached to the project. For example, { "environment": "production", "team": "backend" }