Minor 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.
- duplicates
-
JENKINS-20989 PeepholePermalink RunListenerImpl oncompleted should be triggered before downstream builds are triggered
-
- Resolved
-
[JENKINS-27635] Downstream build can start running before upstream build has completed
| 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 |
| 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} |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
| 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. |
| Link |
New:
This issue duplicates |
| Resolution | New: Duplicate [ 3 ] | |
| Status | Original: In Progress [ 3 ] | New: Resolved [ 5 ] |
| Labels | Original: pipeline trigger | New: trigger |
| Workflow | Original: JNJira [ 161847 ] | New: JNJira + In-Review [ 196882 ] |