|
||||||||
|
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 |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Should combineQueuedCommits=true result in a single long downstream build (even if its upstream ran multiple times)? If so, it does not appear to work for me.
My simple test with Jenkins 1.480.2 (LTE), Git plugin 1.1.26, Paramtrigger plugin: 2.16:
1) new job: try-combinecommits-downstream
scm: a tiny git repo
build step: shell "sleep 120"
2) new job: try-combinecommits-base,
scm: the same repo, trigger by push notification
build step: shell "sleep 10"
trigger parametrized build: try-combinecommits-downstream,
param: Git SHA1
combineQueuedCommits: yes
3) a simple bash loop to pushed dummy changes dozens of times
Result: the short upstream job triggers the downsteam one for each build, flooding the queue - no sign of "combining" them, ie. to pick the last build. I'd expect a second trigger should remove the first one off the queue.
Do I miss anything? Thanks.