Simplified PlaceholderTask

[jglick]

Working on the same test as in #353, I found a (locally unreproducible) case where it appears that Queue.cancel from PlaceholderTask.Callback.finished triggered CancelledItemListener. PlaceholderTask.stopping was designed to prevent exactly this; the fact that it did not suggests that there are multiple PlaceholderTasks involved. As in #344, the root design flaw is that there is mutable state in PlaceholderTask yet it is difficult to ensure Java object identity here. So here I am moving the stopping field to transient global state (RunningTasks). I am also restoring cookie to its original purpose of an actual environment variable value used for nothing more than killing off stray background processes at the end of the block; and using StepContext as the primary key whenever we need to look up state. I did consider making PlaceholderTask actually immutable but this would require changing the storage of the label and cookie fields, which is more difficult for two reasons: we need to actually read these values from builds running before the upgrade; and we would need to find some other spot to persist them (such as fields in ExecutorStepExecution perhaps). I think these fields are not real problems anyway, since they are only mutated once, in PlaceholderExecutable.run, and before that point there does not seem to be a risk of there being multiple copies of the PlaceholderTask: the known problems involve deserialization from both the queue and from ExecutorStepDynamicContext.task, but ExecutorStepDynamicContext is not created until after cookie and label have been written.

[jglick]

(just better encapsulation)

[jglick]

Reverting this bit of #344 which should now be unnecessary: any instances in memory ought to be interchangeable at this point.

[jglick]

Reducing noise and redundancy. CpsStepContext.toString already encodes the Run#externalizableId; and cookie is now rarely interesting. auth was never interesting unless you installed authorized-project, now deprecated.

[jglick]

(hide whitespace)

[jglick]

Unclear why this was here, when the PlaceholderExecutable is not Serializable.

stale

[dwnusbaum]

If d1a2aa2 fixes test failures in PCT, would it make sense to add a test (or multiple tests) here for whatever it is fixing?

[jglick]

Probably yes. The clear problem was the willContinue implementation, which caused a test using mock-slave to keep an ephemeral agent online after its node block ended, and thus to be reused rather than a new agent being created. This seems to have been the cause of more subtle issues in other tests as well. I think I can find a more focused way to reproduce that. (Maybe a test using OnceRetentionStrategy needs to be introduced? I do not particularly want to add a test dep on mock-slave however.)

While working on that I noticed that Callback.finished may not have been running all of its logic consistently, since finish had been remove the RunningTask entry (which led to a broader reworking of the timing of this entry’s addition and removal). I am not really sure how critical a problem that was: it did not appear to result in any PCT failures.

[jglick]

Did not notice in #323 that PipelineOnlyTaskDispatcher was not actually getting loaded. (queueTaskOwnerCorrectWhenRestarting passed with or without it.)

[jglick]

Without d1a2aa2, fails

java.lang.AssertionError: 

Expected: a string containing "Running on test-2"
     but: was "Started
[Pipeline] Start of Pipeline
[Pipeline] node
Running on test-1 in …/agents/test-1/workspace/p
[Pipeline] {
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: SUCCESS
"
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
	at org.jvnet.hudson.test.JenkinsRule.assertLogContains(JenkinsRule.java:1518)
	at org.jenkinsci.plugins.workflow.support.steps.ExecutorStep2Test.lambda$cloud$2(ExecutorStep2Test.java:121)