Updates an existing webhook configuration. Permissions required: bb.projects.update
The list of fields to update.
If set to true, and the webhook is not found, a new webhook will be created.
In this situation, update_mask is ignored.
Webhook integration type. type is the type of the webhook.
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_UNSPECIFIED, ISSUE_CREATE, ISSUE_COMMENT_CREATE, ISSUE_FIELD_UPDATE, ISSUE_STATUS_UPDATE, ISSUE_PIPELINE_STAGE_STATUS_UPDATE, ISSUE_APPROVAL_NOTIFY, ISSUE_PIPELINE_TASK_RUN_STATUS_UPDATE, NOTIFY_ISSUE_APPROVED, NOTIFY_PIPELINE_ROLLOUT OK
The name of the project. Format: projects/{project}
The lifecycle state of the project.
STATE_UNSPECIFIED, ACTIVE, DELETED The title or name of a project. It's not unique within the workspace.
The list of webhooks configured for the project.
The data classification configuration ID for the project.
Labels available for tagging issues in this project.
Force issue labels to be used when creating an issue.
Allow modifying SQL statements after issue is created.
Enable automatic issue resolution when tasks complete.
Enforce issue title to be created by user instead of generated by Bytebase.
Whether to automatically enable backup for database changes.
Whether to skip backup errors and continue with data migration.
Whether to enable database tenant mode for PostgreSQL. If enabled, issues will include "set role <db_owner>" statement.
Whether to allow issue creators to self-approve their own issues.
Execution retry policy for task runs.
The maximum number of database rows to sample during CI data validation. Without specification, sampling is disabled, resulting in full validation.
The maximum number of parallel tasks allowed during rollout execution.
Labels are key-value pairs that can be attached to the project. For example, { "environment": "production", "team": "backend" }
Whether to enforce SQL review checks to pass before issue creation. If enabled, issues cannot be created when SQL review finds errors.
Whether to require issue approval before rollout.
Whether to require plan check to have no error before rollout.