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

Text Finder 1.13 no longer supports setting the build result when a match is not found

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: text-finder-plugin
    • Labels:
      None
    • Environment:
      Jenkins 2.235.1
      text finder 1.13
    • Similar Issues:
    • Released As:
      1.14

      Description

      I use text finder to scan the console logs of freestyle jobs that are part of my Jenkins test environment . The changes in text-finder 1.13 seem to have caused all searches for console text to mark the job as having succeeded, even if the text being searched is not in the console log.

      Steps to duplicate the problem:

      1. Define a new freestyle job (I named mine JENKINS-62734-text-finder-always-finds-console-text)
      2. Add a build step "Execute shell" with the command "date;echo Hello JENKINS-62734"
      3. Add a post-build action "Text finder" that succeeds if found and additionally searches console output for
        ^Hello JENKINS-62734$
        
      1. Run the job and confirm with text-finder 1.12 and 1.13 that the job succeeds
      2. Change the searched text to
        ^Goodbye JENKINS-62734$
        
      1. Run the job and confirm with text-finder 1.12 that the job fails as expected
      2. Run the job and confirm with text-finder 1.13 that the job succeeds unexpectedly

      It also appears that there are more states available for the text-finder 1.12 plugin than are available in text-finder 1.13.

      The text-finder 1.12 plugin states seem to generate the following job status results (with question marks at places where I haven't yet gathered the data):

      Succeed if found Unstable if found Not Built if found Text in console log Text not in console log
      False False False Failed Succeed
      False False True Not Built Succeed
      False True False Unstable Succeed
      False True True Not Built Succeed
      True False False Succeed Fail
      True False True Succeed Not Built
      True True False Succeed Unstable
      True True True Succeed Not Built

        Attachments

          Issue Links

            Activity

            Hide
            basil Basil Crow added a comment - - edited

            Thanks for reporting this. Needless to say, the old API was not intuitive. Yes, the new API does not support all the states that the old API supported. I think an intuitive way of supporting all the old states would be to keep the "build result" field from 1.13 but add a "condition under which to change result" boolean. The combination of these two fields can support all the old states:

            Build result Condition under which to change result Text in console log Text not in console log
            SUCCESS Match found SUCCESS SUCCESS
            UNSTABLE Match found UNSTABLE SUCCESS
            FAILURE Match found FAILURE SUCCESS
            NOT_BUILT Match found NOT_BUILT SUCCESS
            ABORTED Match found ABORTED SUCCESS
            SUCCESS Match not found SUCCESS SUCCESS
            UNSTABLE Match not found SUCCESS UNSTABLE
            FAILURE Match not found SUCCESS FAILURE
            NOT_BUILT Match not found SUCCESS NOT_BUILT
            ABORTED Match not found SUCCESS ABORTED

            The migration path would be as follows:

            Succeed if found Unstable if found Not Built if found Build result Condition under which to change result
            False False False FAILURE Match found
            False False True NOT_BUILT Match found
            False True False UNSTABLE Match found
            False True True NOT_BUILT Match found
            True False False FAILURE Match not found
            True False True NOT_BUILT Match not found
            True True False UNSTABLE Match not found
            True True True NOT_BUILT Match not found

            If you compare the results from the old API with the results from the new API (using the above migration rubric), the build results match.

            I think the new API modified with the "Condition under which to change result" field is far more intuitive than the old API was.

            Does this make sense to you, Mark Waite? If so, I'll prepare a PR with this new option and the abovementioned migration logic.

            Show
            basil Basil Crow added a comment - - edited Thanks for reporting this. Needless to say, the old API was not intuitive. Yes, the new API does not support all the states that the old API supported. I think an intuitive way of supporting all the old states would be to keep the "build result" field from 1.13 but add a "condition under which to change result" boolean. The combination of these two fields can support all the old states: Build result Condition under which to change result Text in console log Text not in console log SUCCESS Match found SUCCESS SUCCESS UNSTABLE Match found UNSTABLE SUCCESS FAILURE Match found FAILURE SUCCESS NOT_BUILT Match found NOT_BUILT SUCCESS ABORTED Match found ABORTED SUCCESS SUCCESS Match not found SUCCESS SUCCESS UNSTABLE Match not found SUCCESS UNSTABLE FAILURE Match not found SUCCESS FAILURE NOT_BUILT Match not found SUCCESS NOT_BUILT ABORTED Match not found SUCCESS ABORTED The migration path would be as follows: Succeed if found Unstable if found Not Built if found ⇨ Build result Condition under which to change result False False False → FAILURE Match found False False True → NOT_BUILT Match found False True False → UNSTABLE Match found False True True → NOT_BUILT Match found True False False → FAILURE Match not found True False True → NOT_BUILT Match not found True True False → UNSTABLE Match not found True True True → NOT_BUILT Match not found If you compare the results from the old API with the results from the new API (using the above migration rubric), the build results match. I think the new API modified with the "Condition under which to change result" field is far more intuitive than the old API was. Does this make sense to you, Mark Waite ? If so, I'll prepare a PR with this new option and the abovementioned migration logic.
            Hide
            basil Basil Crow added a comment -

            Take a look at the proposed new API in jenkinsci/text-finder-plugin#55 and let me know what you think and if it resolves your issue. If it looks good, I'll write some automated tests for it and do a release.

            Show
            basil Basil Crow added a comment - Take a look at the proposed new API in jenkinsci/text-finder-plugin#55 and let me know what you think and if it resolves your issue. If it looks good, I'll write some automated tests for it and do a release.
            Hide
            markewaite Mark Waite added a comment -

            Looks good to me. Initial interactive testing was successful

            Show
            markewaite Mark Waite added a comment - Looks good to me. Initial interactive testing was successful
            Hide
            basil Basil Crow added a comment -
            Show
            basil Basil Crow added a comment - Fixed in jenkinsci/text-finder-plugin#55 .
            Hide
            basil Basil Crow added a comment -

            Released in 1.14.

            Show
            basil Basil Crow added a comment - Released in 1.14 .
            Hide
            basil Basil Crow added a comment -

            Released in 1.14.

            Show
            basil Basil Crow added a comment - Released in 1.14 .

              People

              Assignee:
              basil Basil Crow
              Reporter:
              markewaite Mark Waite
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: