• Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • branch-api-plugin

      Right now it seems not possible tho disable a pipeline project that is part of a multibranch pipeline project. There is no UI element to do it. Maybe deleted branches should be disabled automatically, or an other kind of indication should be added to the project list?

          [JENKINS-35144] UI for disabled branch projects

          Oleg Nenashev added a comment -

          Since it's related to JENKINS-35143, I presume the issue is about Pipeline multibranch

          Oleg Nenashev added a comment - Since it's related to JENKINS-35143 , I presume the issue is about Pipeline multibranch

          Jesse Glick added a comment -

          Projects for deleted branches are deleted automatically if the orphaned item strategy says so. However, if it does not, it would make sense for BranchJobProperty to set WorkflowJob.isBuildable to false if !branch.isBuildable.

          Jesse Glick added a comment - Projects for deleted branches are deleted automatically if the orphaned item strategy says so. However, if it does not, it would make sense for BranchJobProperty to set WorkflowJob.isBuildable to false if !branch.isBuildable .

          We should keep scenarios in might were the branch is not yet deleted, but you might want to prevent further builds for a while (for what ever reason).

          Martin Heinzerling added a comment - We should keep scenarios in might were the branch is not yet deleted, but you might want to prevent further builds for a while (for what ever reason).

          Patrick Wolf added a comment -

          This seems related to JENKINS-32396 - Option to suppress automatic SCM trigger

          JENKINS-32396 provides an option in the UI to suppress builds matching a pattern from executing. This met the use case of suppressing all automatic builds of designated jobs but does not allow for suppressing future builds of the job via the pipeline script itself. A "property" in pipeline to enable this suppression, if possible, would work here. The first build with the property would still run, even if it didn't do anything but set the property, but subsequent runs would not be triggered.

          Patrick Wolf added a comment - This seems related to JENKINS-32396 - Option to suppress automatic SCM trigger JENKINS-32396 provides an option in the UI to suppress builds matching a pattern from executing. This met the use case of suppressing all automatic builds of designated jobs but does not allow for suppressing future builds of the job via the pipeline script itself. A "property" in pipeline to enable this suppression, if possible, would work here. The first build with the property would still run, even if it didn't do anything but set the property, but subsequent runs would not be triggered.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          src/main/java/org/jenkinsci/plugins/workflow/multibranch/BranchJobProperty.java
          http://jenkins-ci.org/commit/workflow-multibranch-plugin/64ab4bbdef7210a9e9a2eca55f8db805e24a1cea
          Log:
          Deleting comment filed as JENKINS-35144.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/java/org/jenkinsci/plugins/workflow/multibranch/BranchJobProperty.java http://jenkins-ci.org/commit/workflow-multibranch-plugin/64ab4bbdef7210a9e9a2eca55f8db805e24a1cea Log: Deleting comment filed as JENKINS-35144 .

          Jesse Glick added a comment -

          Not related hrmpw; an orphaned branch project would not get any automatic builds anyway, since there is no more branch to receive commits, but currently manual builds are not disabled.

          Jesse Glick added a comment - Not related hrmpw ; an orphaned branch project would not get any automatic builds anyway, since there is no more branch to receive commits, but currently manual builds are not disabled.

          Pipeline children are always enabled until they become orphaned... at which point they are automatically disabled... there was a bug in pipeline multibranch w.r.t. permissions but that should have been fixed by https://github.com/jenkinsci/workflow-multibranch-plugin/commit/b2a46915ad0eea00ddd8c11c36ff3d29dfc0c524#diff-70d4cb71c24ac78397a2cae536830bf0

          Stephen Connolly added a comment - Pipeline children are always enabled until they become orphaned... at which point they are automatically disabled... there was a bug in pipeline multibranch w.r.t. permissions but that should have been fixed by https://github.com/jenkinsci/workflow-multibranch-plugin/commit/b2a46915ad0eea00ddd8c11c36ff3d29dfc0c524#diff-70d4cb71c24ac78397a2cae536830bf0

          Nick Jones added a comment -

          For what it's worth, we just encountered a use case for this: all our Jenkins nodes (including master) are on Windows, and a branch was pushed and then renamed, changing only its case (from "bugs..." to "Bugs..."). The Jenkins branch build got triggered twice – probably once for each name variant – then branch indexing ran and tried to remove the older variant, but failed (with a stack trace), as the newer folder was still in use, and as branch indexing kept trying to run and failing, the builds kept getting triggered over and over (two at a time). We finally stopped it by removing the Jenkinsfile from the branch and aborting the currently executing jobs, but being able to disable that particular branch in the Jenkins UI would have been much more convenient.

          I should note that this environment is using the v1 Branch API (1.11.1), SCM API (1.3), etc. series of plugins – we haven't yet updated our production Jenkins environment until the patches for these settle down. But I'm not expecting that the newer versions would fix this particular issue.

          Nick Jones added a comment - For what it's worth, we just encountered a use case for this: all our Jenkins nodes (including master) are on Windows, and a branch was pushed and then renamed, changing only its case (from "bugs..." to "Bugs..."). The Jenkins branch build got triggered twice – probably once for each name variant – then branch indexing ran and tried to remove the older variant, but failed (with a stack trace), as the newer folder was still in use, and as branch indexing kept trying to run and failing, the builds kept getting triggered over and over (two at a time). We finally stopped it by removing the Jenkinsfile from the branch and aborting the currently executing jobs, but being able to disable that particular branch in the Jenkins UI would have been much more convenient. I should note that this environment is using the v1 Branch API (1.11.1), SCM API (1.3), etc. series of plugins – we haven't yet updated our production Jenkins environment until the patches for these settle down. But I'm not expecting that the newer versions would fix this particular issue.

          Robby Pocase added a comment -

          I think there are valid use cases for this in multi-branch projects. There are a number of ways to disable triggering in the source code (overrideIndexTriggers, disable polling, etc), but this doesn't advertise any intent in the UI that the job should be disabled. In cases where I have shared pipeline templates, this affects ALL consuming jobs. I may just want to disable a handful of jobs.

          I'd really like to see this issue reopened, even if it is low priority for the maintainers.

          Robby Pocase added a comment - I think there are valid use cases for this in multi-branch projects. There are a number of ways to disable triggering in the source code (overrideIndexTriggers, disable polling, etc), but this doesn't advertise any intent in the UI that the job should be disabled. In cases where I have shared pipeline templates, this affects ALL consuming jobs. I may just want to disable a handful of jobs. I'd really like to see this issue reopened, even if it is low priority for the maintainers.

          Jesse Glick added a comment -

          this doesn't advertise any intent in the UI that the job should be disabled

          That could be improved.

          In cases where I have shared pipeline templates, this affects ALL consuming jobs. I may just want to disable a handful of jobs.

          Already possible.

          Jesse Glick added a comment - this doesn't advertise any intent in the UI that the job should be disabled That could be improved. In cases where I have shared pipeline templates, this affects ALL consuming jobs. I may just want to disable a handful of jobs. Already possible.

          Jesse Glick added a comment -

          (To clarify, orphaned branch projects are already shown in strikethrough in the list view. But there is no visual indication of branch projects for which the index trigger is disabled.)

          Jesse Glick added a comment - (To clarify, orphaned branch projects are already shown in strikethrough in the list view. But there is no visual indication of branch projects for which the index trigger is disabled.)

          Robby Pocase added a comment -

          I was more focused on the issue title than body. For deleted branches, I think the UI is already pretty clear. Having a small UI element clearly indicating it's disabled doesn't hurt though

          jglick Could you clarify on how to disable subsets of jobs when using a shared pipeline? The only option I can think of are by changing the branch of the shared pipeline in the multibranch, but this doesn't work in the GitHub Organization context (unless you have multiple orgs consuming the same pipeline).

          I may be making an invalid assumption that this issue was mostly targeting branch source jobs. If so, I can write a new issue specifically against it.

          Robby Pocase added a comment - I was more focused on the issue title than body. For deleted branches, I think the UI is already pretty clear. Having a small UI element clearly indicating it's disabled doesn't hurt though jglick Could you clarify on how to disable subsets of jobs when using a shared pipeline? The only option I can think of are by changing the branch of the shared pipeline in the multibranch, but this doesn't work in the GitHub Organization context (unless you have multiple orgs consuming the same pipeline). I may be making an invalid assumption that this issue was mostly targeting branch source jobs. If so, I can write a new issue specifically against it.

          Jesse Glick added a comment -

          how to disable subsets of jobs when using a shared pipeline?

          A library? Well the library can dynamically determine which jobs should be disabled, using whatever criteria are appropriate for your situation. There is no fundamental difference from this case vs. inlining everything in every Jenkinsfile.

          Jesse Glick added a comment - how to disable subsets of jobs when using a shared pipeline? A library? Well the library can dynamically determine which jobs should be disabled, using whatever criteria are appropriate for your situation. There is no fundamental difference from this case vs. inlining everything in every Jenkinsfile .

          Robby Pocase added a comment -

          I actually meant a shared Jenkinsfile. Stuffing the triggers into a shared library would probably work. This wouldn't be as nice to use with declarative since it'd likely have to be outside of a `triggers {}` scope to dynamically load trigger configuration.

          Robby Pocase added a comment - I actually meant a shared Jenkinsfile. Stuffing the triggers into a shared library would probably work. This wouldn't be as nice to use with declarative since it'd likely have to be outside of a `triggers {}` scope to dynamically load trigger configuration.

          Mark Ribau added a comment - - edited

          Please consider this the explanation to go with the +1 vote for having a way to disable individual branches of multi-branch pipelines via UI. Thanks!

          "Normal" Use Cases:
          We currently use multi branch pipelines for nearly all of our jobs. A particular type of "maintenance" job has its individual branches to run perform maintenance for different project releases (e.g. dev vs master vs staging/platform/release-num vs release/platform/release-num). Occasionally, it would be really convenient to disable a particular branch of this maintenance job b/c QA has determined there is a release blocking issue (rather than edit/delete Jenkinsfiles or libraries). Similarly, if we want to temporarily disable a report that we generate via a multi branch pipeline for a particular branch, it also would be useful.

          "Rare" Use/Abuse Case:
          We have encountered another use case, but expect it is very uncommon: In this particular multi branch pipeline, we have a dummy repo where we create branches that correspond to project names (e.g. name of a repo), and perform a common set of operations on these repos for other teams we support. We had received a request to temporarily disable these operations for a repo. Our solution was to delete the branch and recreate it later, but it would have been very convenient to just disable/re-enable the branch via UI. We are fully aware that this is abusing the multi branch pipeline system, but are unsure how common such a thing is. It has been extremely useful for us.

          Mark Ribau added a comment - - edited Please consider this the explanation to go with the +1 vote for having a way to disable individual branches of multi-branch pipelines via UI. Thanks! "Normal" Use Cases: We currently use multi branch pipelines for nearly all of our jobs. A particular type of "maintenance" job has its individual branches to run perform maintenance for different project releases (e.g. dev vs master vs staging/platform/release-num vs release/platform/release-num). Occasionally, it would be really convenient to disable a particular branch of this maintenance job b/c QA has determined there is a release blocking issue (rather than edit/delete Jenkinsfiles or libraries). Similarly, if we want to temporarily disable a report that we generate via a multi branch pipeline for a particular branch, it also would be useful. "Rare" Use/Abuse Case: We have encountered another use case, but expect it is very uncommon: In this particular multi branch pipeline, we have a dummy repo where we create branches that correspond to project names (e.g. name of a repo), and perform a common set of operations on these repos for other teams we support. We had received a request to temporarily disable these operations for a repo. Our solution was to delete the branch and recreate it later, but it would have been very convenient to just disable/re-enable the branch via UI. We are fully aware that this is abusing the multi branch pipeline system, but are unsure how common such a thing is. It has been extremely useful for us.

          I have a use case very similar to the "Normal use case" stated above, where a "Release" branch can be enabled or disabled manually depending on several heuristic factors (load on the site, urgency of a hotfix, etc).

          Currently we have different individual jobs where we can disable each step as needed. We are migrating to a more generic multibranch pipeline, but this is holding us, as we can no longer disable individual steps.

          Is there any plan on working on this in a near future?

          Francisco Santos added a comment - I have a use case very similar to the "Normal use case" stated above, where a "Release" branch can be enabled or disabled manually depending on several heuristic factors (load on the site, urgency of a hotfix, etc). Currently we have different individual jobs where we can disable each step as needed. We are migrating to a more generic multibranch pipeline, but this is holding us, as we can no longer disable individual steps. Is there any plan on working on this in a near future?

          Jesse Glick added a comment -

          Not that I know of. Someone could write a plugin which uses https://javadoc.jenkins.io/hudson/model/Queue.QueueDecisionHandler.html#shouldSchedule(hudson.model.Queue.Task,java.util.List) to reject attempts to build selected jobs.

          Jesse Glick added a comment - Not that I know of. Someone could write a plugin which uses https://javadoc.jenkins.io/hudson/model/Queue.QueueDecisionHandler.html#shouldSchedule(hudson.model.Queue.Task,java.util.List ) to reject attempts to build selected jobs.

          Francisco Santos added a comment - - edited

          Isn't it overkill to implement a plugin just to skip the execution for a "disabled" branch?.

          Also, it'd need to also implement the "disabling" of the branch.

          Francisco Santos added a comment - - edited Isn't it overkill to implement a plugin just to skip the execution for a "disabled" branch?. Also, it'd need to also implement the "disabling" of the branch.

            Unassigned Unassigned
            mheinzerling Martin Heinzerling
            Votes:
            8 Vote for this issue
            Watchers:
            18 Start watching this issue

              Created:
              Updated: