## Summary When **Branches for which notifications are to be sent** in the **Pipeline status emails** integration is set to `default`, `protected`, or `default_and_protected`, a tag-triggered pipeline does not correctly check the branch associated with the tag. As a result, no email notification is sent. The email is sent successfully when the setting is changed to `all`. This issue is intended to: * Confirm whether this problem still exists in the current GitLab version. * Collect similar problems related to the **Pipeline status emails** integration. * Fix the missing default or protected branch check for tag-triggered pipelines. Related issues: * [Receive notification for tagging triggered pipelines failure](https://gitlab.com/gitlab-org/gitlab/-/issues/555428) * [Receive notification for scheduled and tagged pipelines](https://gitlab.com/gitlab-org/gitlab/-/issues/235121) ## Steps to reproduce 1. Create a project with a configured and working CI/CD pipeline. 2. Enable the **Pipeline status emails** integration. 3. Add a valid email recipient and enable pipeline notifications. If the project does not have a pipeline that is guaranteed to fail, do not enable **Notify only broken pipelines**, as the pipeline status could otherwise affect the reproduction. 4. Set **Branches for which notifications are to be sent** to `protected`. 5. Create a tag for a commit on a protected branch. 6. Wait for the tag-triggered pipeline to finish. The same problem can also be observed when the setting is `default` or `default_and_protected`. ## Current behavior When a pipeline is triggered by a tag, the branch-filtering logic does not check whether the branch associated with the tag is the default branch or a protected branch. Consequently, no pipeline status email is sent. The email is sent successfully when **Branches for which notifications are to be sent** is changed to `all`. ## Expected behavior When a pipeline is triggered by a tag, the system should check the branch associated with the commit referenced by that tag and decide whether to send an email according to the **Branches for which notifications are to be sent** setting: * When set to `default`, send the notification if the branch associated with the tag is the default branch. * When set to `protected`, send the notification if the branch associated with the tag is a protected branch. * When set to `default_and_protected`, send the notification if the branch associated with the tag is either the default branch or a protected branch. * When set to `all`, preserve the existing behavior. Tag-triggered pipelines should perform the same default or protected branch checks as branch-triggered pipelines, rather than treating the tag name directly as a branch name. ## Root cause analysis Based on source-code analysis, `Integrations::Base::PipelinesEmail#should_pipeline_be_notified?` calls `NotificationBranchSelection#notify_for_branch?` for pipeline events. For a tag-triggered pipeline: * `object_attributes.ref` contains the tag name. * `object_attributes.sha` contains the SHA of the commit referenced by the tag. * `object_attributes.tag` indicates that this is a tag pipeline. The current `notify_for_branch?` implementation: * compares the tag name in `object_attributes.ref` with `project.default_branch`; and * passes the tag name to `ProtectedBranch.protected?`. The tag name is therefore evaluated as though it were a branch name. The existing logic does not use the commit referenced by the tag to find the associated branches, nor does it check whether those branches are the default branch or protected branches. As a result, the branch-filtering condition does not match and the pipeline status email is skipped. ## Impact Many teams use tags to trigger build, release, or deployment pipelines. When pipeline status emails are limited to the default branch or protected branches, tag-triggered pipelines might not send status emails. Pipeline failures and other important status changes can therefore go unnoticed. Setting the branch selection to `all` is a temporary workaround, but it can also generate unwanted notifications for unrelated branches or tags. ## Call for similar reports :postbox: We would appreciate help from maintainers and community members in confirming the following: 1. Is the tag pipeline email notification behavior described in [issue 555428](https://gitlab.com/gitlab-org/gitlab/-/issues/555428) caused by the same problem? 2. Is the scheduled and tag pipeline notification behavior described in [issue 235121](https://gitlab.com/gitlab-org/gitlab/-/issues/235121) caused by the same problem? 3. Are there any other missing, duplicated, or incorrectly filtered notifications involving the **Pipeline status emails**integration? If possible, please include the following information in your comment: * The GitLab version and whether you are using GitLab.com or Self-Managed. * How the pipeline was triggered, such as by a branch, tag, schedule, or upstream/downstream pipeline. * The configured value of **Branches for which notifications are to be sent**. * The final pipeline status. * Whether **Notify only broken pipelines** was enabled. * The number of emails received, or confirmation that no email was received. If you have encountered a similar pipeline status email problem, please leave a comment on this issue. We would like to collect and evaluate these related reports together.