|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
- [JIRA] (JENKINS-16384) Blocking on downstream p... [email protected] (JIRA)
- [JIRA] (JENKINS-16384) Blocking on downstr... [email protected] (JIRA)
- [JIRA] (JENKINS-16384) Blocking on downstr... [email protected] (JIRA)
- [JIRA] (JENKINS-16384) Blocking on downstr... [email protected] (JIRA)
- [JIRA] (JENKINS-16384) Blocking on downstr... [email protected] (JIRA)
- [JIRA] (JENKINS-16384) Blocking on downstr... [email protected] (JIRA)
- [JIRA] (JENKINS-16384) Blocking on downstr... [email protected] (JIRA)
- [JIRA] (JENKINS-16384) Blocking on downstr... [email protected] (JIRA)
- [JIRA] (JENKINS-16384) Blocking on downstr... [email protected] (JIRA)
- [JIRA] (JENKINS-16384) Blocking on downstr... [email protected] (JIRA)

I have added the Slave Prerequisites plugin to Job E (without the block upstream enabled) and that seems to block job A as expected even if job E is started from other places.
This is because the plugin blocks at the executor level and the block on downstream check does include queued jobs.
So cannot see a particular cause of why Job A should run if Job E is in the queue, unless it is a timing issue in that when the join trigger schedules job E it is not seen by Job A when it does its checks which is probably Queue related item.
Which I cannot really investigate unless there is a particular case that can be seen causing job A to run instead of job E.
If you can get logs on why Job E is being blocked in the queue, before Job A is started then a particular case might be found that can be invistigated.