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

Downstream build can start running before upstream build has completed

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Minor Minor
    • core

      This is a problem in case downstream build refers to the build of a parent project by permalink such as LAST_SUCCESSFUL and expect it will match the exact build that triggered the downstream build. This is a reasonable expectation if downstream build is triggered for stable/successful builds only.

      I observed several downstream builds copied different versions of artifacts from upstream project. Due to a heavily contended queue it took ~2 minutes to schedule all downstream builds using hudson.tasks.BuildTrigger. And as the actual scheduling is done before upstream completes, several downstream builds was scheduled fast enough to observe old permalink value.

          [JENKINS-27635] Downstream build can start running before upstream build has completed

          Oliver Gondža created issue -
          Oliver Gondža made changes -
          Description Original: This is a problem in case downstream build refers to the build of a parent project by permalink such as {{LAST_SUCCESSFUL}} and expect it will match the exact build that triggered the downstream build. This is a reasonable expectation if downstream build is triggered for stable/successful builds only.

          I observed several downstream builds copied different versions of artifacts from upstream project. Due to a heavily contended queue it took ~2 minutes to schedule all downstream builds using {{hudson.tasks.BuildTrigger}}. And as the actual scheduling is done before upstream completes, several downstream builds was scheduled fast enough to observe old permalink value.

          the scheduling should take place *after* upstream build is done.

          Btw, I was not able to find any documentation for the assumption that upstream and downstream build should not overlap in time.           		New: This is a problem in case downstream build refers to the build of a parent project by permalink such as {{LAST_SUCCESSFUL}} and expect it will match the exact build that triggered the downstream build. This is a reasonable expectation if downstream build is triggered for stable/successful builds only.

          I observed several downstream builds copied different versions of artifacts from upstream project. Due to a heavily contended queue it took ~2 minutes to schedule all downstream builds using {{hudson.tasks.BuildTrigger}}. And as the actual scheduling is done before upstream completes, several downstream builds was scheduled fast enough to observe old permalink value.

          The scheduling should take place *after* upstream build is done.

          Btw, I was not able to find any documentation for the assumption that upstream and downstream build should not overlap in time.
          Labels New: pipeline trigger
          Oliver Gondža made changes -
          Description Original: This is a problem in case downstream build refers to the build of a parent project by permalink such as {{LAST_SUCCESSFUL}} and expect it will match the exact build that triggered the downstream build. This is a reasonable expectation if downstream build is triggered for stable/successful builds only.

          I observed several downstream builds copied different versions of artifacts from upstream project. Due to a heavily contended queue it took ~2 minutes to schedule all downstream builds using {{hudson.tasks.BuildTrigger}}. And as the actual scheduling is done before upstream completes, several downstream builds was scheduled fast enough to observe old permalink value.

          The scheduling should take place *after* upstream build is done.

          Btw, I was not able to find any documentation for the assumption that upstream and downstream build should not overlap in time.           		New: This is a problem in case downstream build refers to the build of a parent project by permalink such as {{LAST_SUCCESSFUL}} and expect it will match the exact build that triggered the downstream build. This is a reasonable expectation if downstream build is triggered for stable/successful builds only.

          I observed several downstream builds copied different versions of artifacts from upstream project. Due to a heavily contended queue it took ~2 minutes to schedule all downstream builds using {{hudson.tasks.BuildTrigger}}. And as the actual scheduling is done before upstream completes, several downstream builds was scheduled fast enough to observe old permalink value.

          The scheduling should take place *after* upstream build is done.

          EDIT: Nothing special needs to happen actually. This is what upstream is doing at the time single downstream runs in unittest without any artificial slowdowns.
          {noformat}
          "Executor #1 for master : executing test0 #1" #35 prio=5
             java.lang.Thread.State: RUNNABLE
          at java.net.URLStreamHandler.parseURL(URLStreamHandler.java:265)
          at sun.net.www.protocol.file.Handler.parseURL(Handler.java:67)
          at java.net.URL.<init>(URL.java:614)
          - locked <0xb31a06e> (a java.util.jar.JarFile)
          at java.net.URL.<init>(URL.java:482)
          at sun.misc.URLClassPath$FileLoader.getResource(URLClassPath.java:1058)
          at sun.misc.URLClassPath.getResource(URLClassPath.java:199)
          at java.net.URLClassLoader$1.run(URLClassLoader.java:358)
          at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
          at java.security.AccessController.doPrivileged(Native Method)
          at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
          at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
          - locked <0x671b9b7f> (a java.lang.Object)
          at java.lang.Class.getDeclaredMethods0(Native Method)
          at java.lang.Class.privateGetDeclaredMethods(Class.java:2615)
          at java.lang.Class.getDeclaredMethod(Class.java:2007)
          at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.getMethod(SerializationMethodInvoker.java:165)
          at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.getMethod(SerializationMethodInvoker.java:170)
          at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.getMethod(SerializationMethodInvoker.java:170)
          at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.getMethod(SerializationMethodInvoker.java:170)
          at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.getMethod(SerializationMethodInvoker.java:149)
          at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.callWriteReplace(SerializationMethodInvoker.java:86)
          at hudson.util.RobustReflectionConverter.marshal(RobustReflectionConverter.java:99)
          at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
          at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
          - locked <0x457de3bb> (a java.lang.Object)
          at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
          at com.thoughtworks.xstream.core.TreeMarshaller.start(TreeMarshaller.java:82)
          at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.marshal(AbstractTreeMarshallingStrategy.java:37)
          at com.thoughtworks.xstream.XStream.marshal(XStream.java:1026)
          at com.thoughtworks.xstream.XStream.marshal(XStream.java:1015)
          at com.thoughtworks.xstream.XStream.toXML(XStream.java:988)
          at hudson.XmlFile.write(XmlFile.java:178)
          at hudson.model.Run.save(Run.java:1898)
          at hudson.model.Run.execute(Run.java:1795)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
          at hudson.model.ResourceController.execute(ResourceController.java:89)
          at hudson.model.Executor.run(Executor.java:263)
          - locked <0x4bf22da1> (a java.lang.Object)
          {noformat}
          Oliver Gondža made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Oliver Gondža made changes -
          Description Original: This is a problem in case downstream build refers to the build of a parent project by permalink such as {{LAST_SUCCESSFUL}} and expect it will match the exact build that triggered the downstream build. This is a reasonable expectation if downstream build is triggered for stable/successful builds only.

          I observed several downstream builds copied different versions of artifacts from upstream project. Due to a heavily contended queue it took ~2 minutes to schedule all downstream builds using {{hudson.tasks.BuildTrigger}}. And as the actual scheduling is done before upstream completes, several downstream builds was scheduled fast enough to observe old permalink value.

          The scheduling should take place *after* upstream build is done.

          EDIT: Nothing special needs to happen actually. This is what upstream is doing at the time single downstream runs in unittest without any artificial slowdowns.
          {noformat}
          "Executor #1 for master : executing test0 #1" #35 prio=5
             java.lang.Thread.State: RUNNABLE
          at java.net.URLStreamHandler.parseURL(URLStreamHandler.java:265)
          at sun.net.www.protocol.file.Handler.parseURL(Handler.java:67)
          at java.net.URL.<init>(URL.java:614)
          - locked <0xb31a06e> (a java.util.jar.JarFile)
          at java.net.URL.<init>(URL.java:482)
          at sun.misc.URLClassPath$FileLoader.getResource(URLClassPath.java:1058)
          at sun.misc.URLClassPath.getResource(URLClassPath.java:199)
          at java.net.URLClassLoader$1.run(URLClassLoader.java:358)
          at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
          at java.security.AccessController.doPrivileged(Native Method)
          at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
          at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
          - locked <0x671b9b7f> (a java.lang.Object)
          at java.lang.Class.getDeclaredMethods0(Native Method)
          at java.lang.Class.privateGetDeclaredMethods(Class.java:2615)
          at java.lang.Class.getDeclaredMethod(Class.java:2007)
          at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.getMethod(SerializationMethodInvoker.java:165)
          at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.getMethod(SerializationMethodInvoker.java:170)
          at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.getMethod(SerializationMethodInvoker.java:170)
          at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.getMethod(SerializationMethodInvoker.java:170)
          at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.getMethod(SerializationMethodInvoker.java:149)
          at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.callWriteReplace(SerializationMethodInvoker.java:86)
          at hudson.util.RobustReflectionConverter.marshal(RobustReflectionConverter.java:99)
          at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
          at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
          - locked <0x457de3bb> (a java.lang.Object)
          at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
          at com.thoughtworks.xstream.core.TreeMarshaller.start(TreeMarshaller.java:82)
          at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.marshal(AbstractTreeMarshallingStrategy.java:37)
          at com.thoughtworks.xstream.XStream.marshal(XStream.java:1026)
          at com.thoughtworks.xstream.XStream.marshal(XStream.java:1015)
          at com.thoughtworks.xstream.XStream.toXML(XStream.java:988)
          at hudson.XmlFile.write(XmlFile.java:178)
          at hudson.model.Run.save(Run.java:1898)
          at hudson.model.Run.execute(Run.java:1795)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
          at hudson.model.ResourceController.execute(ResourceController.java:89)
          at hudson.model.Executor.run(Executor.java:263)
          - locked <0x4bf22da1> (a java.lang.Object)
          {noformat}
          		 New: This is a problem in case downstream build refers to the build of a parent project by permalink such as {{LAST_SUCCESSFUL}} and expect it will match the exact build that triggered the downstream build. This is a reasonable expectation if downstream build is triggered for stable/successful builds only.

          I observed several downstream builds copied different versions of artifacts from upstream project. Due to a heavily contended queue it took ~2 minutes to schedule all downstream builds using {{hudson.tasks.BuildTrigger}}. And as the actual scheduling is done before upstream completes, several downstream builds was scheduled fast enough to observe old permalink value.
          Oliver Gondža made changes -
          Link New: This issue duplicates JENKINS-20989 [ JENKINS-20989 ]

          Oliver Gondža added a comment -

          Closing as a duplicate of JENKINS-20989.

          Oliver Gondža added a comment - Closing as a duplicate of JENKINS-20989 .
          Oliver Gondža made changes -
          Resolution New: Duplicate [ 3 ]
          Status Original: In Progress [ 3 ] New: Resolved [ 5 ]

          SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Oliver Gondža
          Path:
          core/src/main/java/hudson/model/Run.java
          test/src/test/java/hudson/tasks/BuildTriggerTest.java
          http://jenkins-ci.org/commit/jenkins/ad56599e5c54d9a5f850f365ca0ff969d7c7f87d
          Log:
          Merge pull request #1628 from olivergondza/JENKINS-27635

          JENKINS-20989 PeepholePermalink RunListenerImpl oncompleted should be triggered before downstream builds are triggered

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Oliver Gondža Path: core/src/main/java/hudson/model/Run.java test/src/test/java/hudson/tasks/BuildTriggerTest.java http://jenkins-ci.org/commit/jenkins/ad56599e5c54d9a5f850f365ca0ff969d7c7f87d Log: Merge pull request #1628 from olivergondza/ JENKINS-27635 JENKINS-20989 PeepholePermalink RunListenerImpl oncompleted should be triggered before downstream builds are triggered
          Jesse Glick made changes -
          Labels Original: pipeline trigger New: trigger

            olivergondza Oliver Gondža
            olivergondza Oliver Gondža
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: