[JENKINS-76023] Add support to disable individual branch jobs in Multibranch Pipeline projects. #554
Description
Description:
In Multibranch Pipeline projects, branch jobs are automatically managed by Jenkins through the Branch API. Currently, there is no way to selectively disable a branch job in the GUI (or persistently via API). Users can only:
- Remove branches from indexing via filters (wildcards, build strategies).
- Add conditional logic in Jenkinsfile to skip builds.
- Delete branches or rely on SCM clean-up.
This makes it difficult to archive or temporarily disable specific branches while preserving their history.
Proposal:
Introduce the ability to disable/enable individual branch jobs in a Multibranch Pipeline, similar to Freestyle or standalone Pipeline jobs.
Acceptance Criteria:
- A “Disable Project” action is available on each branch job page.
- Disabled branch jobs are marked in the Jenkins UI (e.g., greyed out, labelled “disabled”).
- A disabled branch job will not trigger automatically, nor accept manual builds.
- The disabled state persists across branch indexing/re-scans.
- REST/API endpoints support /disable and /enable for branch jobs.
Advantages:
- ✅ Provides fine-grained control over which branches should build.
- ✅ Preserves build history and logs while stopping future builds.
- ✅ Avoids SCM changes (no need to edit Jenkinsfile to skip).
- ✅ Useful for archiving release or feature branches.
- ✅ Reduces unnecessary CI/CD load for obsolete branches.
Disadvantages / Considerations:
⚠️ Conflicts slightly with Branch API philosophy (automatic job management).
⚠️ Requires persistence of disabled state across SCM indexing.
⚠️ Needs careful handling of Job.Configure permissions to prevent misuse.
⚠️ May create user confusion if disabled branches remain visible but unbuildable.
Use Cases:
- A team wants to archive release-1.0 but keep build logs, without deleting it.
- Temporarily disabling noisy branches that are causing build queue congestion.
- Selectively disabling legacy branches while continuing to build active ones.
Originally reported by maduka14, imported from: Add support to disable individual branch jobs in Multibranch Pipeline projects.
- assignee:
aytuncbeken
- status: Open
- priority: Major
- component(s): workflow-multibranch-plugin
- label(s): multi-branch, rfe, usability
- resolution: Unresolved
- votes: 1
- watchers: 2
- imported: 20251212-090250
Raw content of original issue
Description: In Multibranch Pipeline projects, branch jobs are automatically managed by Jenkins through the Branch API. Currently, there is no way to selectively disable a branch job in the GUI (or persistently via API). Users can only:
- Remove branches from indexing via filters (wildcards, build strategies).
- Add conditional logic in Jenkinsfile to skip builds.
- Delete branches or rely on SCM clean-up.
This makes it difficult to archive or temporarily disable specific branches while preserving their history.
Proposal: Introduce the ability to disable/enable individual branch jobs in a Multibranch Pipeline, similar to Freestyle or standalone Pipeline jobs.
Acceptance Criteria:
- A “Disable Project” action is available on each branch job page.
- Disabled branch jobs are marked in the Jenkins UI (e.g., greyed out, labelled “disabled”).
- A disabled branch job will not trigger automatically, nor accept manual builds.
- The disabled state persists across branch indexing/re-scans.
- REST/API endpoints support /disable and /enable for branch jobs.
Advantages:
- ✅ Provides fine-grained control over which branches should build.
- ✅ Preserves build history and logs while stopping future builds.
- ✅ Avoids SCM changes (no need to edit Jenkinsfile to skip).
- ✅ Useful for archiving release or feature branches.
- ✅ Reduces unnecessary CI/CD load for obsolete branches.
Disadvantages / Considerations:
- ⚠️ Conflicts slightly with Branch API philosophy (automatic job management).
- ⚠️ Requires persistence of disabled state across SCM indexing.
- ⚠️ Needs careful handling of Job.Configure permissions to prevent misuse.
- ⚠️ May create user confusion if disabled branches remain visible but unbuildable.
Use Cases:
- A team wants to archive release-1.0 but keep build logs, without deleting it.
- Temporarily disabling noisy branches that are causing build queue congestion.
- Selectively disabling legacy branches while continuing to build active ones.