Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-15115

FitNesse: Option to mark build unstable when fitnesse tests fail (amber not red)

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • fitnesse-plugin
    • None

      FitNesse explicitly fails the build, overriding the default Jenkins/Hudson behaviour to mark the build as unstable when a test fails (such as a junit unit or integration test).

      This causes us some build process problems. We use post-build checks to run Sonar for static analysis. We want this to run if the build is unstable, but not broken, to get the most out of Sonar's trending information. In this way, we can adopt test-driven development with continuous code quality analysis. Unfortunately there is no satisfactory workaround to use FitNesse with Sonar as intended. We can configure Sonar to run even when the build is broken, but then we lose the benefit of the default configuration of Sonar for maven projects, and it is not the correct process either (it does not make sense to analyse broken code).

      I see on github that mhoswell has forked the plugin and removed the getBuildResult() method override in class FitnesseResults. That would fix our problem. However, I am guessing that some users rely upon the current behaviour? Also, I see no evidence of a pull request.

      My proposal is to provide an option to control whether or not the default Jenkins behaviour is overriden by FitNesse or not:

      When FitNesse tests fail mark build as: (dropdown box failed|unstable)

      I think unstable is expected behaviour and would prefer that as the default, but then existing users might prefer existing behaviour to be left alone! Would be interested to know what others think? I am happy to make the changes and put in a pull request.

      With Regards
      Rob

          [JENKINS-15115] FitNesse: Option to mark build unstable when fitnesse tests fail (amber not red)

          Rob Platt created issue -
          Rob Platt made changes -
          Description Original: FitNesse explicitly fails the build, overriding the default Jenkins/Hudson behaviour to mark the build as unstable when a test fails.

          This causes us some build process problems. We use post-build checks to run Sonar for static analysis. We want this to run if the build is unstable, but not broken, to get the most out of Sonar's trending information.

          There is no satisfactory workaround to use Sonar and FitNesse together. We can configure Sonar to run even when the build is broken, but this is not quite the correct process either.

          I see on github that mhoswell has forked the plugin and removed the getBuildResult() method override in class FitnesseResults. That would fix our problem. However, I am guessing that some users rely upon the current behaviour? Also, I see no evidence of a pull request.

          My proposal is to provide an option to control whether or not the default Jenkins behaviour is overriden by FitNesse or not:

          When there are FitNesse tests fail mark build as: (dropdown box failed|unstable)

          I think unstable is expected behaviour and would prefer that as the default, but then existing users might prefer existing behaviour as default! Would be interested to know what others think? I am happy to make the changes and put in a pull request.

          With Regards
          Rob
          New: FitNesse explicitly fails the build, overriding the default Jenkins/Hudson behaviour to mark the build as unstable when a test fails.

          This causes us some build process problems. We use post-build checks to run Sonar for static analysis. We want this to run if the build is unstable, but not broken, to get the most out of Sonar's trending information. There is no satisfactory workaround to use Sonar and FitNesse together. We can configure Sonar to run even when the build is broken, but this is not quite the correct process either.

          I see on github that mhoswell has forked the plugin and removed the getBuildResult() method override in class FitnesseResults. That would fix our problem. However, I am guessing that some users rely upon the current behaviour? Also, I see no evidence of a pull request.

          My proposal is to provide an option to control whether or not the default Jenkins behaviour is overriden by FitNesse or not:

          When FitNesse tests fail mark build as: (dropdown box failed|unstable)

          I think unstable is expected behaviour and would prefer that as the default, but then existing users might prefer existing behaviour as default! Would be interested to know what others think? I am happy to make the changes and put in a pull request.

          With Regards
          Rob
          Rob Platt made changes -
          Description Original: FitNesse explicitly fails the build, overriding the default Jenkins/Hudson behaviour to mark the build as unstable when a test fails.

          This causes us some build process problems. We use post-build checks to run Sonar for static analysis. We want this to run if the build is unstable, but not broken, to get the most out of Sonar's trending information. There is no satisfactory workaround to use Sonar and FitNesse together. We can configure Sonar to run even when the build is broken, but this is not quite the correct process either.

          I see on github that mhoswell has forked the plugin and removed the getBuildResult() method override in class FitnesseResults. That would fix our problem. However, I am guessing that some users rely upon the current behaviour? Also, I see no evidence of a pull request.

          My proposal is to provide an option to control whether or not the default Jenkins behaviour is overriden by FitNesse or not:

          When FitNesse tests fail mark build as: (dropdown box failed|unstable)

          I think unstable is expected behaviour and would prefer that as the default, but then existing users might prefer existing behaviour as default! Would be interested to know what others think? I am happy to make the changes and put in a pull request.

          With Regards
          Rob
          New: FitNesse explicitly fails the build, overriding the default Jenkins/Hudson behaviour to mark the build as unstable when a test fails.

          This causes us some build process problems. We use post-build checks to run Sonar for static analysis. We want this to run if the build is unstable, but not broken, to get the most out of Sonar's trending information. There is no satisfactory workaround to use Sonar and FitNesse together. We can configure Sonar to run even when the build is broken, but then we lose the benefit of the default configuration of Sonar for maven projects, and it is not the correct process either.

          I see on github that mhoswell has forked the plugin and removed the getBuildResult() method override in class FitnesseResults. That would fix our problem. However, I am guessing that some users rely upon the current behaviour? Also, I see no evidence of a pull request.

          My proposal is to provide an option to control whether or not the default Jenkins behaviour is overriden by FitNesse or not:

          When FitNesse tests fail mark build as: (dropdown box failed|unstable)

          I think unstable is expected behaviour and would prefer that as the default, but then existing users might prefer existing behaviour as default! Would be interested to know what others think? I am happy to make the changes and put in a pull request.

          With Regards
          Rob
          Rob Platt made changes -
          Summary Original: FitNesse: Option not to only mark build unstable when fitnesse tests fail New: FitNesse: Option to only mark build unstable when fitnesse tests fail
          Rob Platt made changes -
          Description Original: FitNesse explicitly fails the build, overriding the default Jenkins/Hudson behaviour to mark the build as unstable when a test fails.

          This causes us some build process problems. We use post-build checks to run Sonar for static analysis. We want this to run if the build is unstable, but not broken, to get the most out of Sonar's trending information. There is no satisfactory workaround to use Sonar and FitNesse together. We can configure Sonar to run even when the build is broken, but then we lose the benefit of the default configuration of Sonar for maven projects, and it is not the correct process either.

          I see on github that mhoswell has forked the plugin and removed the getBuildResult() method override in class FitnesseResults. That would fix our problem. However, I am guessing that some users rely upon the current behaviour? Also, I see no evidence of a pull request.

          My proposal is to provide an option to control whether or not the default Jenkins behaviour is overriden by FitNesse or not:

          When FitNesse tests fail mark build as: (dropdown box failed|unstable)

          I think unstable is expected behaviour and would prefer that as the default, but then existing users might prefer existing behaviour as default! Would be interested to know what others think? I am happy to make the changes and put in a pull request.

          With Regards
          Rob
          New: FitNesse explicitly fails the build, overriding the default Jenkins/Hudson behaviour to mark the build as unstable when a test fails (i.e. jUnit test).

          This causes us some build process problems. We use post-build checks to run Sonar for static analysis. We want this to run if the build is unstable, but not broken, to get the most out of Sonar's trending information. In this way, we can adopt test-driven development with continuous code quality analysis. Unfortunately there is no satisfactory workaround to use FitNesse with Sonar as intended. We can configure Sonar to run even when the build is broken, but then we lose the benefit of the default configuration of Sonar for maven projects, and it is not the correct process either (it does not make sense to analyse broken code).

          I see on github that mhoswell has forked the plugin and removed the getBuildResult() method override in class FitnesseResults. That would fix our problem. However, I am guessing that some users rely upon the current behaviour? Also, I see no evidence of a pull request.

          My proposal is to provide an option to control whether or not the default Jenkins behaviour is overriden by FitNesse or not:

          When FitNesse tests fail mark build as: (dropdown box failed|unstable)

          I think unstable is expected behaviour and would prefer that as the default, but then existing users might prefer existing behaviour to be left alone! Would be interested to know what others think? I am happy to make the changes and put in a pull request.

          With Regards
          Rob
          Summary Original: FitNesse: Option to only mark build unstable when fitnesse tests fail New: FitNesse: Option to mark build unstable when fitnesse tests fail (amber not red)
          Rob Platt made changes -
          Description Original: FitNesse explicitly fails the build, overriding the default Jenkins/Hudson behaviour to mark the build as unstable when a test fails (i.e. jUnit test).

          This causes us some build process problems. We use post-build checks to run Sonar for static analysis. We want this to run if the build is unstable, but not broken, to get the most out of Sonar's trending information. In this way, we can adopt test-driven development with continuous code quality analysis. Unfortunately there is no satisfactory workaround to use FitNesse with Sonar as intended. We can configure Sonar to run even when the build is broken, but then we lose the benefit of the default configuration of Sonar for maven projects, and it is not the correct process either (it does not make sense to analyse broken code).

          I see on github that mhoswell has forked the plugin and removed the getBuildResult() method override in class FitnesseResults. That would fix our problem. However, I am guessing that some users rely upon the current behaviour? Also, I see no evidence of a pull request.

          My proposal is to provide an option to control whether or not the default Jenkins behaviour is overriden by FitNesse or not:

          When FitNesse tests fail mark build as: (dropdown box failed|unstable)

          I think unstable is expected behaviour and would prefer that as the default, but then existing users might prefer existing behaviour to be left alone! Would be interested to know what others think? I am happy to make the changes and put in a pull request.

          With Regards
          Rob
          New: FitNesse explicitly fails the build, overriding the default Jenkins/Hudson behaviour to mark the build as unstable when a test fails (such as a junit unit or integration test).

          This causes us some build process problems. We use post-build checks to run Sonar for static analysis. We want this to run if the build is unstable, but not broken, to get the most out of Sonar's trending information. In this way, we can adopt test-driven development with continuous code quality analysis. Unfortunately there is no satisfactory workaround to use FitNesse with Sonar as intended. We can configure Sonar to run even when the build is broken, but then we lose the benefit of the default configuration of Sonar for maven projects, and it is not the correct process either (it does not make sense to analyse broken code).

          I see on github that mhoswell has forked the plugin and removed the getBuildResult() method override in class FitnesseResults. That would fix our problem. However, I am guessing that some users rely upon the current behaviour? Also, I see no evidence of a pull request.

          My proposal is to provide an option to control whether or not the default Jenkins behaviour is overriden by FitNesse or not:

          When FitNesse tests fail mark build as: (dropdown box failed|unstable)

          I think unstable is expected behaviour and would prefer that as the default, but then existing users might prefer existing behaviour to be left alone! Would be interested to know what others think? I am happy to make the changes and put in a pull request.

          With Regards
          Rob
          Antoine Aumjaud made changes -
          Assignee Original: Rob Platt [ rpdai ] New: Stanimir Stamenkov [ stanio ]
          Resolution New: Fixed [ 1 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]
          Antoine Aumjaud made changes -
          Status Original: Resolved [ 5 ] New: Closed [ 6 ]
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 145835 ] New: JNJira + In-Review [ 206138 ]

            stanio Stanimir Stamenkov
            rpdai Rob Platt
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: