Can't create webhooks via Api for build events.

Summary

Based on Api documentation I can't actually create a webhook for a project that listens to build events. I think this relates to EE and CE. I'm reproing this on gitlab.com.

The api documentation refers to job_events, but get requests on webhooks I created via the gitlab.com UI using the JOB EVENTS checkbox return build_event: true.

  {
    "wiki_page_events": false,
    "pipeline_events": false,
    "build_events": true,
    "note_events": false,
    "merge_requests_events": false,
    "issues_events": false,
    "project_id": ****,
    "enable_ssl_verification": true,
    "tag_push_events": false,
    "push_events": false,
    "created_at": "2017-04-03T07:22:31.869Z",
    "url": "****",
    "id": ****
  }

However if I try to post using the api and including the build_events=true parameter.

{
  "error": "build_events is invalid"
}

If I include job_events=true then I get a 201 response, but build_events is not set to true in the GET request, and the UI doesn't include build events being sent to the webhook.

  {
    "wiki_page_events": false,
    "pipeline_events": false,
    "build_events": false,
    "note_events": false,
    "merge_requests_events": false,
    "issues_events": false,
    "project_id": ****,
    "enable_ssl_verification": true,
    "tag_push_events": false,
    "push_events": false,
    "created_at": "2017-04-03T21:14:41.329Z",
    "url": "****",
    "id": ****
  }

Steps to reproduce

Perform a Post request to the hooks endpoint and expect to be able to set the build_events flag.

What is the current bug behavior?

I'm blocked from being able to create webhooks appropriately via the api. Which is blocking my ability to create webhooks across multiple projects.

What is the expected correct behavior?

The ability to add webhooks via the api that include build_events or job_events. Whatever the name is for receiving messages on a per execution within the ci.

Output of checks

This bug happens on GitLab.com

Possible fixes

Not exactly sure all the places that would need to be updated, but this looks like it needs to be updated to job_events: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/api/project_hooks.rb#L16

Documentation stating job_events: https://docs.gitlab.com/ce/api/projects.html#add-project-hook

@srokadia Thanks for the report. On GitLab.com I noticed the following behaviors:

• POST /api/v3/projects:/id/hooks with build_events=true creates a webhook with "push_events": true and "job_events": true
• POST /api/v3/projects:/id/hooks with job_events=true creates a webhook with "push_events": true and "job_events": false => this is expected since the V3 API only uses build_events
• POST /api/v4/projects:/id/hooks with build_events=true creates a webhook with "push_events": true and "job_events": true => The V4 API keeps the backward-compatibility with build_events
• POST /api/v4/projects:/id/hooks with job_events=true creates a webhook with "push_events": true and "job_events": false => The V4 API should handle job_events as an alias for build_events

So it seems to me that the issue is: job_events is not accepted on POST requests for the V4 API.

/cc @zj

added ~19173 ~13884 ~12980 labels

Ill fix this today for v4, v3 works as expected. My bad.

@ayufan @godfat IMO the proper fix would be to rename the build_events column to job_events on web_hooks. This would require a couple of renames elsewhere in the application too, but that would solve it for good.

Else the API would need something ugly like:

params = declared_params
job_event = declared_params.delete(:job_events)
hook = user_project.new(params)
hook.build_params = job_event

hook.save

@zj I think I probably roughly understand what's going on now. Indeed we should rename the column in the long run, but that might need a lot of works and we need to prepare for zero down time migration.

What do you think about fix this first, and we rename the column later? Since it doesn't look too terrible to just fix the API? It's just one place?

mentioned in merge request !10586 (merged)

mentioned in issue #30702 (closed)

assigned to @zj

closed via merge request !10586 (merged)

mentioned in commit a179c5ca

mentioned in commit bff457cc

mentioned in commit 19177205

mentioned in issue #31620 (closed)