When a Merge Request is created from a feature branch toward a target branch, the source feature branch is not automatically removed from the Jenkins multibranch pipeline job, even though the Branch Discovery strategy is set to "Only branches that are not also filed as MRs".
The branch is only removed when a manual scan is triggered afterward.
Environment
- Plugin version: 704.vc7f1202d7e14
- Jenkins version: 2.414.3
- Branch Discovery strategy: Only branches that are not also filed as MRs
- Discover merge requests from origin: enabled
Steps to reproduce
- Configure a Multibranch Pipeline with:
- Branch Discovery → "Only branches that are not also filed as MRs"
- Discover merge requests from origin → enabled
- GitLab webhooks enabled (Push events + Merge request events)
- Push a feature branch (e.g.
feature_test_ahmed_123) → Jenkins discovers it and creates a branch job.
- Create a Merge Request from
feature_test_ahmed_123 → develop in GitLab.
- Observe Jenkins: the branch job
feature_test_ahmed_123 remains visible despite the MR being open.
Expected behavior
When a Merge Request is opened for a branch, Jenkins should automatically remove the branch job (since the strategy is "Only branches not also filed as MRs").
Actual behavior
The branch job persists after MR creation. It is only removed when a manual scan is triggered.
Root cause analysis
When GitLab sends a Merge Request Hook upon MR creation, Jenkins processes it via MultiBranchProject$SCMEventListenerImpl.processHeadUpdate(). This path creates/updates the MR job but does not trigger a re-evaluation of existing branch jobs. As a result, the ExcludeOriginMRBranchesSCMHeadFilter is never applied to the existing branch job at that point.
Evidence from the indexing log when a manual scan is triggered:
Checking branch feature_test_ahmed_123
'Jenkinsfile' found
Met criteria ← branch incorrectly kept before manual scan
Checking merge request !491
'Jenkinsfile' found
Met criteria
...
Will remove feature_test_ahmed_123 ← correctly removed during full scan
Confirmed via GitLab API that the MR is open and source_project_id == target_project_id (not a fork), so the filter conditions are met — the branch just never gets re-evaluated on MR creation.
Also confirmed: after the manual scan removes the branch job, pushing new commits to feature_test_ahmed_123 does not recreate the branch job — the Push Hook path correctly applies the filter. The issue is isolated to the moment of MR creation.
Suggested fix
When a Merge Request Hook of action open is received, trigger a re-evaluation (mini-scan or removal event) for the corresponding source branch, so the filter can apply immediately without waiting for a full scheduled scan.
Workaround
Configure a periodic scan (e.g. every 5 minutes) under "Scan Multibranch Pipeline Triggers → Periodically if not otherwise run". This limits the window during which the phantom branch job is visible.
When a Merge Request is created from a feature branch toward a target branch, the source feature branch is not automatically removed from the Jenkins multibranch pipeline job, even though the Branch Discovery strategy is set to "Only branches that are not also filed as MRs".
The branch is only removed when a manual scan is triggered afterward.
Environment
Steps to reproduce
feature_test_ahmed_123) → Jenkins discovers it and creates a branch job.feature_test_ahmed_123→developin GitLab.feature_test_ahmed_123remains visible despite the MR being open.Expected behavior
When a Merge Request is opened for a branch, Jenkins should automatically remove the branch job (since the strategy is "Only branches not also filed as MRs").
Actual behavior
The branch job persists after MR creation. It is only removed when a manual scan is triggered.
Root cause analysis
When GitLab sends a
Merge Request Hookupon MR creation, Jenkins processes it viaMultiBranchProject$SCMEventListenerImpl.processHeadUpdate(). This path creates/updates the MR job but does not trigger a re-evaluation of existing branch jobs. As a result, theExcludeOriginMRBranchesSCMHeadFilteris never applied to the existing branch job at that point.Evidence from the indexing log when a manual scan is triggered:
Confirmed via GitLab API that the MR is open and
source_project_id == target_project_id(not a fork), so the filter conditions are met — the branch just never gets re-evaluated on MR creation.Also confirmed: after the manual scan removes the branch job, pushing new commits to
feature_test_ahmed_123does not recreate the branch job — the Push Hook path correctly applies the filter. The issue is isolated to the moment of MR creation.Suggested fix
When a
Merge Request Hookof actionopenis received, trigger a re-evaluation (mini-scan or removal event) for the corresponding source branch, so the filter can apply immediately without waiting for a full scheduled scan.Workaround
Configure a periodic scan (e.g. every 5 minutes) under "Scan Multibranch Pipeline Triggers → Periodically if not otherwise run". This limits the window during which the phantom branch job is visible.