[JENKINS-69821] Changes to "built-in" environment variables are ignored always

[jenkins-infra-bot]

Loosely related to JENKINS-27739 - during investigation for jenkinsci/pipeline-groovy-lib-plugin#19 (comment) I found that older ticket and the practical behavior that Jenkins effectively ignores custom envvar settings entered (interactively or programmatically) to the "built-in" node (an instance of MasterComputer model class).

When getEnvironment() is called, it either returns the cachedEnvironment (which might be refreshed for other node types by disconnection and reconnection) or whatever it receives via getChannel() which for "built-in" happens to be envvars set in Jenkins global configuration.

The value from EnvironmentVariablesNodeProperty is not consulted in either codepath, including a full Jenkins JVM restart (since we can not disconnect and reconnect the built-in node).

Reproduction interactively is trivial - edit the "built-in"/"master" node adding non-trivial envvars, restart Jenkins, run a (pipeline) job querying them - they are not resolved.

In plugin test context for a JenkinsRule, rough repro looks like this:

         Computer builtInComputer = r.jenkins.toComputer();
         Node builtInNode = builtInComputer.getNode();
         builtInNode.getNodeProperties().add(new EnvironmentVariablesNodeProperty(new EnvironmentVariablesNodeProperty.Entry("TEST_VAR_NAME", "stable")));
         r.jenkins.save();
         builtInNode.save();

 // Can try to reload, even require repopulation of cache via Java reflection - to no avail...
 // Note that disconnect/connect seems a no-op for MasterComputer instance.
         System.out.println("[DEBUG] Restart the 'built-in' Computer connection to clear its cachedEnvironment and recognize added envvar");
         builtInComputer.setTemporarilyOffline(true, new OfflineCause.ByCLI("Restart built-in to reread envvars config"));
         builtInComputer.disconnect(new OfflineCause.ByCLI("Restart built-in to reread envvars config"));
         builtInComputer.waitUntilOffline();
         r.waitUntilNoActivity();
         builtInComputer.getChannel().close();
         Thread.sleep(3000);
         r.jenkins.reload();
         builtInComputer.setTemporarilyOffline(false, null);
         builtInComputer.connect(true);
         builtInComputer.waitUntilOnline();
         r.waitUntilNoActivity();

         // Feed it to Java reflection, to clear the internal cache...
         Field f = Computer.class.getDeclaredField("cachedEnvironment");
         f.setAccessible(true);
         f.set(builtInComputer, null);

 // Query:
         System.out.println("[DEBUG] builtIn node env: " + builtInComputer.getEnvironment()); 

I would argue this is a bug - either don't let envvars be configured for that node type, or do honour them if present.

---

Originally reported by jimklimov, imported from: Changes to "built-in" environment variables are ignored always

• status: Open
• priority: Major
• component(s): core
• resolution: Unresolved
• votes: 0
• watchers: 1
• imported: 2025-11-24

Raw content of original issue

Loosely related to JENKINS-27739 - during investigation for jenkinsci/pipeline-groovy-lib-plugin#19 (comment) I found that older ticket and the practical behavior that Jenkins effectively ignores custom envvar settings entered (interactively or programmatically) to the "built-in" node (an instance of MasterComputer model class).

When getEnvironment() is called, it either returns the cachedEnvironment (which might be refreshed for other node types by disconnection and reconnection) or whatever it receives via getChannel() which for "built-in" happens to be envvars set in Jenkins global configuration.

The value from EnvironmentVariablesNodeProperty is not consulted in either codepath, including a full Jenkins JVM restart (since we can not disconnect and reconnect the built-in node).

Reproduction interactively is trivial - edit the "built-in"/"master" node adding non-trivial envvars, restart Jenkins, run a (pipeline) job querying them - they are not resolved.

In plugin test context for a JenkinsRule, rough repro looks like this:

         Computer builtInComputer = r.jenkins.toComputer();
         Node builtInNode = builtInComputer.getNode();
         builtInNode.getNodeProperties().add(new EnvironmentVariablesNodeProperty(new EnvironmentVariablesNodeProperty.Entry("TEST_VAR_NAME", "stable")));
         r.jenkins.save();
         builtInNode.save();

         // Can try to reload, even require repopulation of cache via Java reflection - to no avail...
         // Note that disconnect/connect seems a no-op for MasterComputer instance.
         System.out.println("[DEBUG] Restart the 'built-in' Computer connection to clear its cachedEnvironment and recognize added envvar");
         builtInComputer.setTemporarilyOffline(true, new OfflineCause.ByCLI("Restart built-in to reread envvars config"));
         builtInComputer.disconnect(new OfflineCause.ByCLI("Restart built-in to reread envvars config"));
         builtInComputer.waitUntilOffline();
         r.waitUntilNoActivity();
         builtInComputer.getChannel().close();
         Thread.sleep(3000);
         r.jenkins.reload();
         builtInComputer.setTemporarilyOffline(false, null);
         builtInComputer.connect(true);
         builtInComputer.waitUntilOnline();
         r.waitUntilNoActivity();

         // Feed it to Java reflection, to clear the internal cache...
         Field f = Computer.class.getDeclaredField("cachedEnvironment");
         f.setAccessible(true);
         f.set(builtInComputer, null);

         // Query:
         System.out.println("[DEBUG] builtIn node env: " + builtInComputer.getEnvironment()); 

I would argue this is a bug - either don't let envvars be configured for that node type, or do honour them if present.

• environment: 2.289.3 at least