Testing group hooks doesn't lookup projects within nested subgroups

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Summary

If a group hook is created on the top level group, and that group has no direct projects inside it but it contains subgroups that contain projects, the projects within the subgroups aren't picked up when testing the group hook.

When testing a push or merge request event group hook for example, the user will see a Hook execution failed. Ensure the group has a project with commits. message.

PLEASE NOTE: This only affects testing the hook - the group hook will trigger correctly when an actual push or merge request event is generated. This is confusing behaviour because it appears the hook isn't working (when it actually might be working when a real event is generated).

As noted by user, this bug prevents re-enabling a webhook that has been disabled due to too many failures.

Steps to reproduce

1. Create a new top level group ie. top-level-group
2. Create a subgroup ie. top-level-group/subgroup
3. Create a project inside top-level-group/subgroup using one of the templates. The project must contain commits.
4. Create a push and merge request event group hook inside top-level-group and test the hook (this reproduces the error Hook execution failed. Ensure the group has a project with commits.

To get around the problem:

• Add a project containing commits directly into the group where the group hook is being created

What is the current bug behavior?

Group hooks don't lookup projects within subgroups when testing the webhook on push events.

What is the expected correct behavior?

Group hooks should lookup projects within subgroups when testing the webhook on push events.

Relevant logs and/or screenshots

Output of checks

This bug happens on GitLab.com and GitLab 15.6

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)
(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)
(we will only investigate if the tests are passing)

Possible fixes