You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed a couple instances of mavros being doubly queued after the latest release.
With the blocking on upstream the first build should not have started while there were still upstream packages building. We have Block build when upstream project is building enabled. I believe this is some sort of race condition in the queueing/checking for blocking that possibly should be reported upstream.
I've seen this before but never quite as short a trigger queue, nor as repeatable as two arches on the same release.
Details
Build 45 was in the queue, while build 44 was building.
However they were both ultimately triggered by 45539, but it allowed 44 to start despite the fact that upstream jobs were either pending or underway as per the trigger chain for 45.
45 trigger logic
Started by upstream project Kbin_uxv8_uXv8__mavros_msgs__ubuntu_xenial_arm64__binary build number 18
originally caused by:
Started by upstream project Ksrc_uX__mavros_msgs__ubuntu_xenial__source build number 17
originally caused by:
Started by upstream project Krel_trigger-jobs build number 45539
originally caused by:
Started by timer
44 trigger logic
Started by upstream project Ksrc_uX__mavros__ubuntu_xenial__source build number 17
originally caused by:
Started by upstream project Krel_trigger-jobs build number 45539
originally caused by:
Started by timer
Started by upstream project Kbin_uxv8_uXv8__libmavconn__ubuntu_xenial_arm64__binary build number 25
originally caused by:
Started by upstream project Ksrc_uX__libmavconn__ubuntu_xenial__source build number 17
originally caused by:
Started by upstream project Krel_trigger-jobs build number 45539
originally caused by:
Started by timer
Started by upstream project Kbin_uxhf_uXhf__mavros_msgs__ubuntu_xenial_armhf__binary build number 29
originally caused by:
Started by upstream project Ksrc_uX__mavros_msgs__ubuntu_xenial__source build number 17
originally caused by:
Started by upstream project Krel_trigger-jobs build number 45539
originally caused by:
Started by timer
66 triggers:
Started by upstream project Ksrc_uX__mavros__ubuntu_xenial__source build number 17
originally caused by:
Started by upstream project Krel_trigger-jobs build number 45539
originally caused by:
Started by timer
Started by upstream project Kbin_uxhf_uXhf__libmavconn__ubuntu_xenial_armhf__binary build number 44
originally caused by:
Started by upstream project Ksrc_uX__libmavconn__ubuntu_xenial__source build number 17
originally caused by:
Started by upstream project Krel_trigger-jobs build number 45539
originally caused by:
Started by timer
The text was updated successfully, but these errors were encountered:
I noticed a couple instances of mavros being doubly queued after the latest release.
With the blocking on upstream the first build should not have started while there were still upstream packages building. We have
Block build when upstream project is building
enabled. I believe this is some sort of race condition in the queueing/checking for blocking that possibly should be reported upstream.I've seen this before but never quite as short a trigger queue, nor as repeatable as two arches on the same release.
Details
Build 45 was in the queue, while build 44 was building.
However they were both ultimately triggered by 45539, but it allowed 44 to start despite the fact that upstream jobs were either pending or underway as per the trigger chain for 45.
45 trigger logic
44 trigger logic
Dependency listings:
I saw the same behavior on the armhf from the same release: http://build.ros.org/view/Queue/job/Kbin_uxhf_uXhf__mavros__ubuntu_xenial_armhf__binary/
67 triggers:
66 triggers:
The text was updated successfully, but these errors were encountered: