[JENKINS-38669] (3/3) Call FlowDefinition.getSCMs

[AngryGami]

Please see https://issues.jenkins-ci.org/browse/JENKINS-38669 for explanation

Upstream PRs:

• [JENKINS-38669] (1/3) FlowDefinition.getSCMs workflow-api-plugin#111
• [JENKINS-38669] (2/3) CpsScmFlowDefinition.getSCMs workflow-cps-plugin#341

[AngryGami]

Hm... I don't understand why it fails. I didn't change any dependencies in this project or in other PRs that I've made. It fails while enforcing version upper bound for workflow-step-api and script-security both of which are transient and I haven't touched. How to fix that?

[dwnusbaum]

@AngryGami Your dependency updates include other releases besides just your changes, and one of those releases must have updated the version of workflow-step-api or script-security that the dependency requires. To fix it, just update those dependencies in this PR to the most recent version mentioned in the upper bound errors. If they are not already mentioned explicitly in <dependencies>, then add a <dependencyManagement> section that specifies the version instead.

[bitwiseman]

This looks reasonable to me.

[dwnusbaum]

The change looks good, but I'd really like to see a regression test for the user-facing behavior, not just the new method.

If you take a look at WorkflowJobTest.polling() you will see a test that is very similar to the scenario you care about. In that test, the job is built once so that polling can trigger a second build. I think you could create a new test, call it something like firstBuildPolling, and show that you can use the polling endpoint to trigger the first build of the job with these changes. What do you think?

[AngryGami]

I'll try

[dwnusbaum]

Thanks!

[williancolognesitrimble]

any update on it? same problem here.

[jglick]

Sorry this slipped through the cracks for so long! Working on getting this released.