<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=387630) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=387630) </details> <!--IssueSummary end--> <!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "type::bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary Labels to be notified selected in Slack notifications integration are ignored for Pipeline triggers. It seems to work fine if the Note trigger is activated apparently. ### Steps to reproduce Configure in Slack notifications a webhook with "All branches" selected and an arbitrary label in "Labels to be notified", lets say "~monitored" create a MR with no labels and an active pipeline and the webhook will be triggered for the pipeline. ### Example Project https://gitlab.com/virgilx13/slackintegrationexample ### What is the current *bug* behavior? The webhook is triggered even if the MR doesnt have any of the specified labels in "Labels to be notified" ### What is the expected *correct* behavior? The webhook should be triggered only if the MR has the label specified. ### Possible fixes A possible fix is mentioned here: https://gitlab.com/gitlab-org/gitlab/-/issues/387630#note_1333910514. <!-- If you can, link to the line of code that might be responsible for the problem. --> ### Relevant logs and/or screenshots ### Output of checks <!-- If you are reporting a bug on GitLab.com, uncomment below --> This bug happens on GitLab.com #### Results of GitLab environment info <!-- Input any relevant GitLab environment information if needed. --> <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (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`) </pre> </details> #### Results of GitLab application Check <!-- Input any relevant GitLab application check information if needed. --> <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (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) </pre> </details>