into <target branch>` | | Description | Message of the latest commit | Same | Pull request description | | Link | Page of the latest commit | Same | Pull request page | Labels are available for routing and for filtering the change list: | Label | Description | | - | - | | `event` | `push`, `tag` or `pull_request` | | `repo` | Repository path, for example `octo-org/hello-world` | | `repo_id` | Gitee repository id | | `ref` | The pushed branch, or the pull request's target branch (absent on tag pushes) | | `version` | Tag name (tag pushes only) | | `source_branch` | Pull request source branch (pull request merges only) | | `sha` | Commit SHA after the push; the merge commit SHA for a pull request merge | | `actor` | User that triggered the hook (Gitee username) | | `pull_request_id` / `pull_request_number` | `id` / `number` of the pull request (pull request merges only) | ## FAQ *** <AccordionGroup> <Accordion title="Why did every branch push become a change?"> A Gitee WebHook cannot filter by branch. Use the integration's **Routes** to match the `ref` label and assign the branches you care about to a channel, or select only **Tag Push** and **Pull Request**. </Accordion> <Accordion title="Why is there no change after a pull request merge?"> * Check that the WebHook has **Pull Request** selected * Only the merge action creates a change; opening, updating or closing returns success and records nothing * Check the request and Flashduty's response in the WebHook's delivery log </Accordion> <Accordion title="Does resending a notification from Gitee record it twice?"> No. An event with the same change and the same time is recorded once. </Accordion> <Accordion title="Does Test WebHook create a change?"> Gitee's **Test WebHook** sends test data for the selected hook in the same format as a real delivery, so it may create one change. This is expected. </Accordion> <Accordion title="The push returns an InvalidParameter error?"> * `ref is missing`, `after is missing`, `repository.id is missing`, `pull_request.id is missing` or `pull_request is missing`: the payload is incomplete; make sure it comes from a native Gitee WebHook * The body is not JSON: use the current Gitee WebHook (`Content-Type: application/json`); the legacy hook sends a form body and is not supported </Accordion> </AccordionGroup> This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.

> ## Documentation Index > Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt > Use this file to discover all available pages before exploring further. # Gitee change integration > Sync branch pushes, tag pushes and merged pull requests to Flashduty On-call through a Gitee WebHook, as change events you can correlate with alerts and incidents. **Plan requirement**: This feature requires an On-call Standard or higher subscription. [Learn more](https://flashcat.cloud/flashduty/price/) Use a Gitee repository or enterprise WebHook to sync code landing events to Flashduty On-call: each branch push, each newly pushed tag and each merged pull request becomes one Flashduty change with status Done. Gitee WebHooks carry no deployment events; for deployment changes, use the change integration of your deployment tool. A Gitee WebHook cannot filter pushes by branch, so with **Push** selected every push to every branch of the repository becomes a change. Use the `ref` label to route or filter the branches you care about, such as `master` or `release`, in Flashduty.

## In Flashduty On-call *** 1. In the Flashduty console, go to **Integration Center → Change Events** 2. Select **Gitee** and enter an integration name 3. To assign changes to specific channels, add rules under the integration's **Routes** that match labels such as `repo` or `ref` 4. Click **Save** and copy the generated **Push URL**

## Configure Gitee *** Open the repository home page, go to **Manage → WebHooks** and add a WebHook. An enterprise WebHook applies to every repository of the enterprise. You need admin permission on the repository or enterprise. 1. **URL**: paste the full Push URL of the Flashduty integration 2. **Password** and **Signing secret**: leave empty. Flashduty authenticates with the `integration_key` in the Push URL and neither reads nor verifies the password or signature Gitee sends with the request Select the hooks you need: * **Push**: code pushed to a branch * **Tag Push**: a new tag * **Pull Request**: a merged pull request (other pull request actions do not create changes) Do not select **Issue** or **Comment**; they do not create changes. After saving, you can use Gitee's **Test WebHook** to check connectivity. Merging a pull request creates a commit on the target branch. With both **Push** and **Pull Request** selected, one merge can create two changes: the push to the target branch and the pull request merge. If you only need one of them, select only that hook. ## What one change is *** | Gitee object | Change key (change\_key) | Notes | | - | - | - | | Branch push | `push:/@` | Each push has a different commit, so it is a different change; pushing the same commit to the same branch again is the same change | | Tag push | `tag:/@` | A tag of the same name moved to a new commit is a new change | | Pull request merge | `pull_request:/` | Uses the pull request `id` field, not the in-repository `number` | The same commit pushed to two branches is two changes. ## Status mapping *** | Gitee hook | Condition | Flashduty change status | | - | - | - | | Push | push to a branch (`refs/heads/*`) | Done | | Tag Push | push of a tag (`refs/tags/*`) | Done | | Pull Request | `action` is `merge` | Done | Done is an end state, so Flashduty records the change's end time. These deliveries return success and create no change: Issue and comment hooks, pushes that delete a branch or tag, pull request hooks whose `action` is not `merge` (`open`, `update`, `approved`, `close`, `tested`, and so on), and unrecognized hook types. ## Change content *** | Field | Branch push | Tag push | Pull request merge | | - | - | - | - | | Title | `: push ()` | `: tag ` | `: merge # into <target branch>` | | Description | Message of the latest commit | Same | Pull request description | | Link | Page of the latest commit | Same | Pull request page | Labels are available for routing and for filtering the change list: | Label | Description | | - | - | | `event` | `push`, `tag` or `pull_request` | | `repo` | Repository path, for example `octo-org/hello-world` | | `repo_id` | Gitee repository id | | `ref` | The pushed branch, or the pull request's target branch (absent on tag pushes) | | `version` | Tag name (tag pushes only) | | `source_branch` | Pull request source branch (pull request merges only) | | `sha` | Commit SHA after the push; the merge commit SHA for a pull request merge | | `actor` | User that triggered the hook (Gitee username) | | `pull_request_id` / `pull_request_number` | `id` / `number` of the pull request (pull request merges only) | ## FAQ *** <AccordionGroup> <Accordion title="Why did every branch push become a change?"> A Gitee WebHook cannot filter by branch. Use the integration's **Routes** to match the `ref` label and assign the branches you care about to a channel, or select only **Tag Push** and **Pull Request**. </Accordion> <Accordion title="Why is there no change after a pull request merge?"> * Check that the WebHook has **Pull Request** selected * Only the merge action creates a change; opening, updating or closing returns success and records nothing * Check the request and Flashduty's response in the WebHook's delivery log </Accordion> <Accordion title="Does resending a notification from Gitee record it twice?"> No. An event with the same change and the same time is recorded once. </Accordion> <Accordion title="Does Test WebHook create a change?"> Gitee's **Test WebHook** sends test data for the selected hook in the same format as a real delivery, so it may create one change. This is expected. </Accordion> <Accordion title="The push returns an InvalidParameter error?"> * `ref is missing`, `after is missing`, `repository.id is missing`, `pull_request.id is missing` or `pull_request is missing`: the payload is incomplete; make sure it comes from a native Gitee WebHook * The body is not JSON: use the current Gitee WebHook (`Content-Type: application/json`); the legacy hook sends a form body and is not supported </Accordion> </AccordionGroup> This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.