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

Multijob Retry Rules: failure doesn't match the rules

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: multijob-plugin
    • Labels:
      None
    • Environment:
      Jenkins ver. 2.107.2
      Multijob 1.31
    • Similar Issues:

      Description

      Here is how it configured:

      Here is how the concerning rule looks like

      > ls -la /var/lib/jenkins/rules/
      total 32
      drwxrwxr-x.  2 jenkins jenkins  4096 Dec 24 12:21 .
      drwxr-xr-x. 40 jenkins jenkins 12288 Mar 13 09:53 ..
      -rw-rw-r--.  1 jenkins jenkins     3 Jul 12  2017 retry_any_failure.txt
      -rw-rw-r--.  1 jenkins jenkins    18 Jul 12  2017 retry_failure.txt
      -rw-rw-r--.  1 jenkins jenkins    29 Dec 24 12:21 retry_unstable_failure.txt
      -rw-rw-r--.  1 jenkins jenkins    19 Jul 12  2017 retry_unstable.txt
      
      > cat /var/lib/jenkins/rules/retry_any_failure.txt
      .*
      

      The concerning behavior is the following:

      00:57:40 Finished Build : #321: [PR-123] of Job : paralleled_executor with status : FAILURE
      00:57:40 Scanning failed job console output using parsing rule file /var/lib/jenkins/rules/retry_any_failure.txt.
      00:57:40 Failed the build, the failure doesn't match the rules.
      

      How come everything (.*) from retry_any_failure.txt doesn't match the rules (©) ???

      The important caveat here is that this behavior is intermittent; in most cases it works as expected, but this fact confuses even more than it wouldn't work at all...

      Expected behavior

      23:53:35 Finished Build : #456: [PR-654] of Job : another_job with status : FAILURE
      23:53:35 Scanning failed job console output using parsing rule file /var/lib/jenkins/rules/retry_any_failure.txt.
      23:53:35 Known failure detected, retrying this build. Try 1 of 1.
      

        Attachments

          Activity

          Hide
          bahdad Sasha Miroshnychenko added a comment -

          While I'm fairly confident that this issue caused by an implicit misconfiguration on my end, there is still some kind of magic plugin behavior as well...

           

          I decided to double check the job configuration UI and noticed this

          Normally, this would never happen since all my ~1k jobs are configured with JJB, like this (multijob)

          - job:
              name: My_Pipeline
              node: pipeline
              project-type: multijob
              
              parameters:
                - string:
                    name: my_param
          
              wrappers:
                - timestamps
          
              builders:
                - multijob:
                    name: Example subjob
                    condition: SUCCESSFUL
                    projects:
                      - name: paralleled_executor
                        current-parameters: true
                        kill-phase-on: NEVER
                        retry:
                            max-retry: 1
                            strategy-path: "/var/lib/jenkins/rules/retry_any_failure.txt"
          

          As you can see
          strategy-path: "/var/lib/jenkins/rules/retry_any_failure.txt"
          that is being obviously mentioned in multijob logs

          00:57:40 Finished Build : #321: [PR-123] of Job : paralleled_executor with status : FAILURE
          00:57:40 Scanning failed job console output using parsing rule file /var/lib/jenkins/rules/retry_any_failure.txt.
          00:57:40 Failed the build, the failure doesn't match the rules.
          

           ... in reality, doesn't match to the rule from the global jenkins configuration:
          UnstableOrFailure: /var/lib/jenkins/rules/retry_unstable_failure.txt
          which is:

          > cat /var/lib/jenkins/rules/retry_unstable_failure.txt
          Finished: (FAILURE|UNSTABLE)
          

          I ended up adding 4th rule with that desired rule-file

          ... and after re-uploading job it shows proper rule (Any) from job configuration UI.

          Show
          bahdad Sasha Miroshnychenko added a comment - While I'm fairly confident that this issue caused by an implicit misconfiguration on my end, there is still some kind of magic  plugin behavior as well...   I decided to double check the job configuration UI and noticed this Normally, this would never happen since all my ~1k jobs are configured with JJB , like this ( multijob ) - job: name: My_Pipeline node: pipeline project-type: multijob parameters: - string: name: my_param wrappers: - timestamps builders: - multijob: name: Example subjob condition: SUCCESSFUL projects: - name: paralleled_executor current-parameters: true kill-phase-on: NEVER retry: max-retry: 1 strategy-path: "/ var /lib/jenkins/rules/retry_any_failure.txt" As you can see strategy-path: "/var/lib/jenkins/rules/retry_any_failure.txt" that is being obviously mentioned in multijob logs 00:57:40 Finished Build : #321: [PR-123] of Job : paralleled_executor with status : FAILURE 00:57:40 Scanning failed job console output using parsing rule file / var /lib/jenkins/rules/retry_any_failure.txt. 00:57:40 Failed the build, the failure doesn't match the rules.  ... in reality, doesn't match to the rule from the global jenkins configuration: UnstableOrFailure: /var/lib/jenkins/rules/retry_unstable_failure.txt which is: > cat / var /lib/jenkins/rules/retry_unstable_failure.txt Finished: (FAILURE|UNSTABLE) I ended up adding 4th rule with that desired rule-file ... and after re-uploading job it shows proper rule ( Any ) from job configuration UI.

            People

            • Assignee:
              Unassigned
              Reporter:
              bahdad Sasha Miroshnychenko
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: