(retry-scheduling) Retry logic when scheduling is not accepted

[sbeaulie]

Before this change the call to scheduleBuild would run a jenkins.getQueue().schedule2() and return
the value of .isAccepted() but there was no logic around the case where it is not accepted.
We have seen instances in production where the console logs would print 'Triggering XYZ'
but that build would never make it to the queue, leading the code to then wait forever
for the completion of an inexisting build.
I assume queue contention when isAccepted() is false and that a retry will get around the
problem.

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your master branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

Tests were fixed because with the change they would run 5 times since there was no return value provided for scheduleBuild. I did not add a specific test for the for loop since this is boilerplate and .isAccepted() is Boolean and only really exercised in production.

[sbeaulie]

paging someone who knows the jenkins code better, I've seen other plugins get the queue item instead of calling .isAccepted() which one is better?

[sbeaulie]

paging someone who knows the jenkins code better, I've seen other plugins get the queue item instead of calling .isAccepted() which one is better?

[jglick]

I assume queue contention when isAccepted() is false and that a retry will get around the problem.

Not necessarily.

This smells like the wrong fix. More likely the caller of scheduleConfigurationBuild is to blame?

BTW I have release permission on this plugin but am not a maintainer really, and recommend switching all uses to Pipeline when possible.