Boolean return from publishers is deprecated, but there is a total mess in all plugins and core about it. New and right variant now is to fail build with throw AbortException. Such errors are not catched in flexible publish and first thrown publisher stops flexible execution for other publishers nevertheless on configured conditions.
      According to my debugging plugin must

      try { perform } catch { return false;} 
      

      somewhere in root calls in addition to boolean return codes

      Executor #1 for master : executing job #73@9386, prio=5, in group 'main', status: 'RUNNING'
      	  at hudson.plugins.git.GitPublisher.perform(GitPublisher.java:281)
      	  at org.jenkins_ci.plugins.run_condition.BuildStepRunner$2.run(BuildStepRunner.java:110)
      	  at org.jenkins_ci.plugins.run_condition.BuildStepRunner$Fail.conditionalRun(BuildStepRunner.java:154)
      	  at org.jenkins_ci.plugins.run_condition.BuildStepRunner.perform(BuildStepRunner.java:105)
      	  at org.jenkins_ci.plugins.flexible_publish.ConditionalPublisher.perform(ConditionalPublisher.java:183)
      	  at org.jenkins_ci.plugins.flexible_publish.FlexiblePublisher.perform(FlexiblePublisher.java:116)
      	  at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
      	  at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:756)
      	  at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:720)
      	  at hudson.model.Build$BuildExecution.post2(Build.java:182)
      	  at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:669)
      	  at hudson.model.Run.execute(Run.java:1731)
      	  at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
      	  at hudson.model.ResourceController.execute(ResourceController.java:88)
      	  at hudson.model.Executor.run(Executor.java:232)
      

      Also if flexible-publish needs itself fail build - it must throw AbortException
      See https://github.com/KostyaSha/git-plugin/commit/3af2af6af273a10e9c5ab4e4d200222bc39c2f3e for example.

          [JENKINS-26936] support thrown from publisher job statuses

          Bug that is Blocker for person must have Blocker status. This broken behavior is Blocker for me because i decided to pass conditional decides to this plugin instead of implementing build status conditionals in my new plugin.

          Kanstantsin Shautsou added a comment - Bug that is Blocker for person must have Blocker status. This broken behavior is Blocker for me because i decided to pass conditional decides to this plugin instead of implementing build status conditionals in my new plugin.

          From "issue tracking documentation" https://issues.jenkins-ci.org/secure/ShowConstantsHelp.jspa#StatusTypes

          Priority Levels
          An issue has a priority level which indicates its importance. The currently defined priorities are listed below. In addition, you can add more priority levels in the administration section.
           Blocker
          Blocks development and/or testing work, production could not run.
          

          Kanstantsin Shautsou added a comment - From "issue tracking documentation" https://issues.jenkins-ci.org/secure/ShowConstantsHelp.jspa#StatusTypes Priority Levels An issue has a priority level which indicates its importance. The currently defined priorities are listed below. In addition, you can add more priority levels in the administration section. Blocker Blocks development and/or testing work, production could not run.

          Daniel Beck added a comment -

          Bug that is Blocker for person must have Blocker status. This broken behavior is Blocker for me because

          This makes every bug a blocker, which obviously makes no sense at all.

          Daniel Beck added a comment - Bug that is Blocker for person must have Blocker status. This broken behavior is Blocker for me because This makes every bug a blocker, which obviously makes no sense at all.

          ikedam added a comment -

          @integer
          This might be a blocker for you, but you didn't explain why it was a blocker, did you?

          I think you only mentioned that flexible-publish should (or must) handle exceptions, and I agree that (https://github.com/jenkinsci/flexible-publish-plugin/pull/9).
          But I don't know why this is a blocker, as users first should make publishers not to throw exceptions and flexible publish enables that with conditional executions.

          I don't care whether this issue is set to a blocker or not, but anyway I don't think I need to work immediately for this issue for now. I'll work in an usual priority.

          Let's describe the exact problem you yourself face, and that must have others want to help you!

          ikedam added a comment - @integer This might be a blocker for you, but you didn't explain why it was a blocker, did you? I think you only mentioned that flexible-publish should (or must) handle exceptions, and I agree that ( https://github.com/jenkinsci/flexible-publish-plugin/pull/9 ). But I don't know why this is a blocker, as users first should make publishers not to throw exceptions and flexible publish enables that with conditional executions. I don't care whether this issue is set to a blocker or not, but anyway I don't think I need to work immediately for this issue for now. I'll work in an usual priority. Let's describe the exact problem you yourself face, and that must have others want to help you!

          Dear, @Daniel Not every bug is a really blocker. Btw it probably first my bug that i set to blocker. I appreciate your "comment every issue" efforts, but if you think that jenkins should not have such status, then feel free to open INFRA issue.

          @ikedam I set issue status according to rules. You changed status without asking initial requestor why it was set to Blocker. So i set it back.

          "But I don't know why this is a blocker, as users first should make publishers not to throw exceptions and flexible publish enables that with conditional executions" - read provided information in PR, boolean is deprecated method for returning publisher statuses and leads for broken flows in post-build actions that depends on correct build statuses. All this statuses is a total mess now, because part of plugins throw exception, part return boolean, part set build status directly, part set status and return failure and etc.

          Ok, I will rework my initial PR. The only thing that i want to hear from maintainer is what behavior is expected for "On evaluation failure" -> "Failure build" because it influence on how we can catch and process this case.

          Kanstantsin Shautsou added a comment - Dear, @Daniel Not every bug is a really blocker. Btw it probably first my bug that i set to blocker. I appreciate your "comment every issue" efforts, but if you think that jenkins should not have such status, then feel free to open INFRA issue. @ikedam I set issue status according to rules. You changed status without asking initial requestor why it was set to Blocker. So i set it back. "But I don't know why this is a blocker, as users first should make publishers not to throw exceptions and flexible publish enables that with conditional executions" - read provided information in PR, boolean is deprecated method for returning publisher statuses and leads for broken flows in post-build actions that depends on correct build statuses. All this statuses is a total mess now, because part of plugins throw exception, part return boolean, part set build status directly, part set status and return failure and etc. Ok, I will rework my initial PR. The only thing that i want to hear from maintainer is what behavior is expected for "On evaluation failure" -> "Failure build" because it influence on how we can catch and process this case.

          Daniel Beck added a comment -

          if you think that jenkins should not have such status, then feel free to open INFRA issue.

          The status has merit, but it should be reserved for severe issues that actually make Jenkins really unusable (worse than occasional crashes, data loss and severe memory leak, which are only 'Critical'). This particular issue looks like 'Major loss of functionality' to me.

          The problem with "This blocks whatever I'm trying to do, so it's a blocker" is that almost every relatively minor bug or unimplemented feature can be considered a blocker because someone, somewhere, planned to use that specific feature, but can't.

          Daniel Beck added a comment - if you think that jenkins should not have such status, then feel free to open INFRA issue. The status has merit, but it should be reserved for severe issues that actually make Jenkins really unusable (worse than occasional crashes, data loss and severe memory leak , which are only 'Critical'). This particular issue looks like 'Major loss of functionality' to me. The problem with "This blocks whatever I'm trying to do, so it's a blocker" is that almost every relatively minor bug or unimplemented feature can be considered a blocker because someone, somewhere, planned to use that specific feature, but can't.

          Kanstantsin Shautsou added a comment - - edited

          I opened root case https://issues.jenkins-ci.org/browse/JENKINS-26964 and build statuses mess looks like a real blocker, because this is broken and i can't use core flow and can't use flexible publish flow. Fixing core is very dangerous, so fixing and using flexible publish for executing all publishers looks right. So this is blocker for usage. Let's better concentrate on fix

          Kanstantsin Shautsou added a comment - - edited I opened root case https://issues.jenkins-ci.org/browse/JENKINS-26964 and build statuses mess looks like a real blocker, because this is broken and i can't use core flow and can't use flexible publish flow. Fixing core is very dangerous, so fixing and using flexible publish for executing all publishers looks right. So this is blocker for usage. Let's better concentrate on fix

          Code changed in jenkins
          User: ikedam
          Path:
          src/test/java/org/jenkins_ci/plugins/flexible_publish/FlexiblePublisherTest.java
          http://jenkins-ci.org/commit/flexible-publish-plugin/f027caae16316b9ae8b3432fa771fd998b92cc82
          Log:
          JENKINS-26936 Added tests for JENKINS-29636, Flexible Publish aborts execution if a publisher throws Exception.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: ikedam Path: src/test/java/org/jenkins_ci/plugins/flexible_publish/FlexiblePublisherTest.java http://jenkins-ci.org/commit/flexible-publish-plugin/f027caae16316b9ae8b3432fa771fd998b92cc82 Log: JENKINS-26936 Added tests for JENKINS-29636 , Flexible Publish aborts execution if a publisher throws Exception.

          ikedam added a comment -

          ikedam added a comment - https://github.com/jenkinsci/flexible-publish-plugin/pull/12

          ikedam added a comment -

          The fix is released in flexible-publish-0.15.
          It will be available in a day.

          ikedam added a comment - The fix is released in flexible-publish-0.15. It will be available in a day.

            ikedam ikedam
            integer Kanstantsin Shautsou
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: