Change NODE_NAME for the built-in node based on its self label

[daniel-beck]

This implements the same terminology cleanup as jenkinsci/jenkins#5425 did in core for for NODE_NAME variable which is set here independently of core.

This is independent of #167 but without that PR, this one will timeout on 2.307+ (unchanged from before).

This is not expected to result in a behavior difference on Jenkins 2.306 and earlier.

On Jenkins 2.307 and later, this PR will change the behavior and make it consistent with core's (freestyle jobs etc.). This can easily be tested by using the script console to provide a custom name and label for the built-in node:

Jenkins.nodeNameAndSelfLabelOverride = 'mast-in'

---

Changelog suggestion:

• The NODE_NAME environment variable value set for the built-in node inside node blocks now matches the behavior of other job types: On Jenkins 2.306 and earlier, the behavior is unchanged (master). On Jenkins 2.307 and later, the variable will be built-in or master, depending on whether the instance was upgraded from a previous release or newly installed, and whether the migration was applied. See https://www.jenkins.io/redirect/built-in-node-migration/

[jglick]

Does

workflow-durable-task-step-plugin/src/main/java/org/jenkinsci/plugins/workflow/support/steps/ExecutorStepExecution.java

Lines 804 to 805 in e53cdd6

	// Switches the label to a self-label, so if the executable is killed and restarted via ExecutorPickle, it will run on the same node:
	label = computer.getName();

still work?

[daniel-beck]

Does

workflow-durable-task-step-plugin/src/main/java/org/jenkinsci/plugins/workflow/support/steps/ExecutorStepExecution.java

Lines 804 to 805 in e53cdd6

	// Switches the label to a self-label, so if the executable is killed and restarted via ExecutorPickle, it will run on the same node:
	label = computer.getName();

still work?

That's the "agent" branch, computer.getName() is weird for the built-in executor, always has been: https://github.com/jenkinsci/jenkins/blob/89d334145d2755f74f82aad07b5df4119d7fa6ce/core/src/main/java/jenkins/model/Jenkins.java#L5092-L5095

[daniel-beck]

Not strictly correct but the best we can do to encourage admins to read the changelog and understand the impact of upgrading.

While there's no dedicated system property for this plugin's behavior, the same jenkins.model.Jenkins.nodeNameAndSelfLabelOverride would change the behavior here.

What's not possible: To get the new behavior as it is in 2.307+ while retaining the existing behavior in this plugin only.

[car-roll]

@jglick do you think your comments fully addressed?

[jglick]

do you think your comments fully addressed?

Other than #168 (comment) yes.

[timja]

could we commit https://github.com/jenkinsci/workflow-durable-task-step-plugin/pull/168/files#r707488266 and 🚢 ?

[daniel-beck]

@car-roll FYI I updated https://github.com/jenkinsci/workflow-durable-task-step-plugin/releases/tag/workflow-durable-task-step-2.40 in response to https://groups.google.com/g/jenkinsci-users/c/R7AUrb6nq5k/m/j_Omo1f3BQAJ; feel free to update/revert.