Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-5925

build.getEnvironment(...) does not include the node environment settings

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • core
    • None

      The email-ext plugin has source that reads:
      getContent(AbstractBuild<P, B> build,...) ... {
      Map<String, String> env = build.getEnvironment(TaskListener.NULL);

      This map does not appear to include environment settings from the node configuration page.

          [JENKINS-5925] build.getEnvironment(...) does not include the node environment settings

          krwalker created issue -

          krwalker added a comment -

          This patch may fix this problem, though I'm not quite sure. Uploading now in case this could help someone else sooner rather than later.

          krwalker added a comment - This patch may fix this problem, though I'm not quite sure. Uploading now in case this could help someone else sooner rather than later.
          krwalker made changes -
          Attachment New: hudson.model.Run.patch [ 19228 ]

          I really like this patch.
          I made changes to a bunch of plugins just to have this env settings accessible.
          I suppose mu patches will be useless if this patch is applied to the Hudson core all the plugins will got this settings.
          Which expands the usefulness of all the plugins.
          Please Mr. Kawaguchi could you apply this patch?

          kostakostadinov added a comment - I really like this patch. I made changes to a bunch of plugins just to have this env settings accessible. I suppose mu patches will be useless if this patch is applied to the Hudson core all the plugins will got this settings. Which expands the usefulness of all the plugins. Please Mr. Kawaguchi could you apply this patch?
          krwalker made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]

          krwalker added a comment -

          After further inspection, I no longer believe file attachment 1 (hudson.model.Run.patch) is an appropriate patch for this bug.

          The bug appears to be caused by Build.RunnerImpl setting AbstractBuild.buildEnvironments = null after all the builders are finished. Because of this, none of the Publishers have access to all of the environment from AbstractBuild.getEnvironment().

          Is it necessary to set buildEnvironments = null at all, and if it is, could this be done at the end of Build.RunnerImpl.cleanUp()?

          Is it appropriate for Publishers to call AbstractBuild.getEnvironment()?

          krwalker added a comment - After further inspection, I no longer believe file attachment 1 (hudson.model.Run.patch) is an appropriate patch for this bug. The bug appears to be caused by Build.RunnerImpl setting AbstractBuild.buildEnvironments = null after all the builders are finished. Because of this, none of the Publishers have access to all of the environment from AbstractBuild.getEnvironment(). Is it necessary to set buildEnvironments = null at all, and if it is, could this be done at the end of Build.RunnerImpl.cleanUp()? Is it appropriate for Publishers to call AbstractBuild.getEnvironment()?
          krwalker made changes -
          Status Original: In Progress [ 3 ] New: Open [ 1 ]

          Alan Harder added a comment -

          I fixed some issues filed against batch-task plugin related to various types of env vars not being present when tasks run, so I hit this problem too. I don't know why those vars are discarded either, but I noted this in a comment in batch_task/BatchRun.java (look for "buildEnvironments are discarded").. you can see the code I used there to get a more complete environment, including node settings and any from "setenv" plugin.

          Alan Harder added a comment - I fixed some issues filed against batch-task plugin related to various types of env vars not being present when tasks run, so I hit this problem too. I don't know why those vars are discarded either, but I noted this in a comment in batch_task/BatchRun.java (look for "buildEnvironments are discarded").. you can see the code I used there to get a more complete environment, including node settings and any from "setenv" plugin.
          Andrew Bayer made changes -
          Assignee New: Andrew Bayer [ abayer ]

          Andrew Bayer added a comment -

          In hudson.model.Build.RunnerImpl.doRun (and the equivalent in Maven builds as well), tearDown is called on each of the environments before they're nulled out - as long as that tearDown call is left, it seems like it'd be fine to move the nulling to cleanUp, as suggested. I'll try that now and see if it breaks anything. =)

          Andrew Bayer added a comment - In hudson.model.Build.RunnerImpl.doRun (and the equivalent in Maven builds as well), tearDown is called on each of the environments before they're nulled out - as long as that tearDown call is left, it seems like it'd be fine to move the nulling to cleanUp, as suggested. I'll try that now and see if it breaks anything. =)

            abayer Andrew Bayer
            krwalker krwalker
            Votes:
            3 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: