• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • core
    • None
    • Windows XP Pro
      Hudson 1.355

      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.

          [JENKINS-6338] Job's cyclic dependency not detected

          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.

          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.

          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.

          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.

          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

          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

          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.

          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.

          Jesse Glick added a comment -

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

          Jesse Glick added a comment - At most this should result in a warning in the configuration screen.

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

              Created:
              Updated: