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

Job's cyclic dependency not detected

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: core
    • Labels:
      None
    • Environment:
      Windows XP Pro
      Hudson 1.355
    • Similar Issues:

      Description

      When playing aroud with job dependencies, configured as free style projects and simple windws batch commands, I discovered that cyclic job dependencies are not detected.
      Neither when saving configuration nor when running the, supposed, "parent" job.
      E.g.
      JobA is configured to trigger another projet (Build Other Project) JobB wich is on its turn configured to trigger JobC.
      And unfortunately, JobA is finally configured to be lauched after JobC is finished ("Build after other projects are built").

      It results in a cyclic execution with absolutely no warning.
      I think that the cyclic dependency should be at least detected at configuration time and should probably forbid the execution of such a set of jobs.

        Attachments

          Issue Links

            Activity

            jlpinardon jlpinardon created issue -
            Hide
            anordman Arne Nordmann added a comment -

            A cyclic job dependency can be even simpler, by just accidentally configuring a job as dependency of itself.
            This should be easy to determine and at least provide a warning in the job configuration interface.

            Show
            anordman Arne Nordmann added a comment - A cyclic job dependency can be even simpler, by just accidentally configuring a job as dependency of itself. This should be easy to determine and at least provide a warning in the job configuration interface.
            Hide
            evernat evernat added a comment -

            Reproduced using Jenkins v1.446:

            When a job "test" is configured to trigger a build of the same job "test", then there is no warning but at least the trigger of the same job is silently excluded from the configuration: clicking on configure again shows that the job is not anymore in the triggers.

            But when a job "test" is configured to trigger a build of the job "test2" and that the job "test2" is configured to trigger the job "test", then the jobs are not excluded from the configuration.
            And when running one of the job, the jobs "test" and "test2" are indefinitely running one after the other ! (fortunately my test jobs have no SCM and no steps so they do nothing).

            It seems easy to detect a cycle among configured jobs when checking or saving the configuration of a job.

            Show
            evernat evernat added a comment - Reproduced using Jenkins v1.446: When a job "test" is configured to trigger a build of the same job "test", then there is no warning but at least the trigger of the same job is silently excluded from the configuration: clicking on configure again shows that the job is not anymore in the triggers. But when a job "test" is configured to trigger a build of the job "test2" and that the job "test2" is configured to trigger the job "test", then the jobs are not excluded from the configuration. And when running one of the job, the jobs "test" and "test2" are indefinitely running one after the other ! (fortunately my test jobs have no SCM and no steps so they do nothing). It seems easy to detect a cycle among configured jobs when checking or saving the configuration of a job.
            Hide
            apetresc Adrian Petrescu added a comment -

            This is affecting us as well – a cycle of length 2 in the dependencies (which is intentional) results in Jenkins recompiling the projects constantly.

            Is there at least any temporary workaround whereby I can manually check what triggered a build when deciding which downstream builds it triggers itself?

            Just throwing ideas out there

            Show
            apetresc Adrian Petrescu added a comment - This is affecting us as well – a cycle of length 2 in the dependencies (which is intentional) results in Jenkins recompiling the projects constantly. Is there at least any temporary workaround whereby I can manually check what triggered a build when deciding which downstream builds it triggers itself? Just throwing ideas out there
            Hide
            danielbeck Daniel Beck added a comment -

            There is code in the build trigger cause to specifically not recurse into parent triggers infinitely. It's safe to assume this is a supported scenario.

            Show
            danielbeck Daniel Beck added a comment - There is code in the build trigger cause to specifically not recurse into parent triggers infinitely. It's safe to assume this is a supported scenario.
            danielbeck Daniel Beck made changes -
            Field Original Value New Value
            Link This issue is related to JENKINS-14814 [ JENKINS-14814 ]
            Hide
            jglick Jesse Glick added a comment -

            At most this should result in a warning in the configuration screen.

            Show
            jglick Jesse Glick added a comment - At most this should result in a warning in the configuration screen.
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 136433 ] JNJira + In-Review [ 174501 ]

              People

              • Assignee:
                Unassigned
                Reporter:
                jlpinardon jlpinardon
              • Votes:
                5 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated: