FlowExecution#getAuthentication2

[basil]

jenkinsci/jenkins#4848

[jglick]

Looks right. Is there a planned impl in https://github.com/jenkinsci/workflow-cps-plugin/blob/d58c465ea71a1d94b1ad827b885b1a5193c9adac/plugin/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsFlowExecution.java#L1566-L1582 https://github.com/jenkinsci/workflow-cps-plugin/blob/d58c465ea71a1d94b1ad827b885b1a5193c9adac/plugin/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsVmExecutorService.java#L172 ? (see jenkinsci/pipeline-plugin@9abf40a)

[basil]

@jglick Yes, such an implementation is planned but not currently assigned to any particular person.

[jglick]

That is fine but this should probably stay on hold until the downstream PR has been prepared, as it is technically introducing a new API.

[basil]

That is fine but this should probably stay on hold until the downstream PR has been prepared

jenkinsci/jenkins#4848 was not held back by the lack of downstream PRs (cf. jenkinsci/reverse-proxy-auth-plugin#153 (comment)), so I see no reason why this PR should stay on hold.

[jglick]

There were some; this method is both implemented and called in only one place (AFAIK), workflow-cps, so it only makes sense to evolve it in the context of those two sites.

(Actually workflow-cps could define and call getAuthentication2 even before it is defined in FlowExecution; it would only be the @Override annotation that would depend on this.)

[basil]

so it only makes sense to evolve it in the context of those two sites

Hence the plan to update those call sites eventually. Is there a particular reason that has to be done as a prerequisite to merging this PR?