Skip to content

Include the changes in issuable webhook payloads

What does this MR do?

This adds a changes key to the issuable webhook payloads, e.g.:

  "changes": {
    "updated_by_id": {
      "previous": null,
      "current": 1
    },
    "updated_at": {
      "previous": "2017-09-15 16:50:55 UTC",
      "current": "2017-09-15 16:52:00 UTC"
    },
    "labels": {
      "previous": [{
        "id": 206,
        "title": "API",
        "color": "#ffffff",
        "project_id": 14,
        "created_at": "2013-12-03T17:15:43Z",
        "updated_at": "2013-12-03T17:15:43Z",
        "template": false,
        "description": "API related issues",
        "type": "ProjectLabel",
        "group_id": 41
      }],
      "current": [{
        "id": 205,
        "title": "Platform",
        "color": "#123123",
        "project_id": 14,
        "created_at": "2013-12-03T17:15:43Z",
        "updated_at": "2013-12-03T17:15:43Z",
        "template": false,
        "description": "Platform related issues",
        "type": "ProjectLabel",
        "group_id": 41
      }]
    }
  }

Are there points in the code the reviewer needs to double check?

  1. I've decided to always include the assignees key since issues and merge requests respond to it, and because MR will soon support multiple assignees, so it doesn't hurt to start returning assignees for MR too. The assignee key is still present for MR, but deprecated.
  2. In the new changes hash, I only included assignees (no assignee) since there is no back-compat to keep here).

Why was this MR needed?

Because some projects need this, see #34284 (moved).

Does this MR meet the acceptance criteria?

What are the relevant issue numbers?

Closes #34284 (moved)

Edited by username-removed-128633

Merge request reports