Do not unregister completed executions when iterating over FlowExecutionList to avoid unnecessary log warnings

[Vlatombe]

cf. jenkinsci/kubernetes-plugin#1342 (comment)

Testing done

AFAIU to reproduce the issue would require to set up a cloud agent. On its termination, it calls indirectly computeNext() which unregisters the FlowExecutionOwner if it is the last node in the pipeline. Then the regular unregister call when the WorkflowRun completes now issues a warning because it has already been unregistered.

Submitter checklist

Preview Give feedback

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

[jglick]

Idea seems right, but we want to keep the unregister call from

workflow-api-plugin/src/main/java/org/jenkinsci/plugins/workflow/flow/FlowExecutionList.java

Lines 198 to 213 in 4521fef

	/**
	* When Jenkins starts up and everything is loaded, be sure to proactively resurrect
	* all the ongoing {@link FlowExecution}s so that they start running again.
	*/
	@Extension
	public static class ItemListenerImpl extends ItemListener {
	@Override
	public void onLoaded() {
	FlowExecutionList list = FlowExecutionList.get();
	for (final FlowExecution e : list) {
	// The call to FlowExecutionOwner.get in the implementation of iterator() is sufficent to load the Pipeline.
	LOGGER.log(Level.FINE, "Eagerly loaded {0}", e);
	}
	list.resumptionComplete = true;
	}
	}

(in some form) as this cleans up stale entries.

[Vlatombe]

@dwnusbaum can you help with review/merge of this fix? Currently holds up another series of PRs (e.g. jenkinsci/kubernetes-plugin#1342)

[dwnusbaum]

@Vlatombe Sure I will look at this today

[dwnusbaum]

@Vlatombe Did you check this against tests in workflow-cps and workflow-job since the new code seems to be not well covered by existing tests in this plugin? I can check it in a minute if you haven't already.

[Vlatombe]

@dwnusbaum no.

To cover the new lines would require a test pipeline involving a cloud agent (so that the agent gets removed at the end of the node block).

[dwnusbaum]

To cover the new lines would require a test pipeline involving cloud agents

It should be possible to set up a relevant test with @LocalData and/or a custom Pipeline step, but either way I mainly just wanted to make sure it didn't affect existing tests in those plugins, and from a quick local check things seem ok.

stale