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

Launcher.ProcStarter.stdout(TaskListener) discards remotability

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None
    • Jenkins 2.136

      When Launcher.ProcStarter.stdout(TaskListener) is called, this is merely an alias for stdout(OutputStream): getLogger() is called on the master side. Whereas the TaskListener passed to RemoteLauncher constructor and used for printCommandLine is properly remoted, that used for process stdout (and bundled stderr) is not.

      When the implementation happened to be a StreamTaskListener, RemoteLauncher.launch winds up wrapping the stream in RemoteOutputStream, so content is still sent back to the master. But an implementation which does something else with the content on the remote side will not be honored.

          [JENKINS-52729] Launcher.ProcStarter.stdout(TaskListener) discards remotability

          Jesse Glick created issue -
          Jesse Glick made changes -
          Link New: This issue blocks JENKINS-38381 [ JENKINS-38381 ]
          Jesse Glick made changes -
          Epic Link New: JENKINS-38313 [ 174485 ]

          Jesse Glick added a comment -

          Likely to be useful for JEP-207.

          From code inspection, I suspect that the simplistic treatment of this overload would also produce mojibake under some conditions in Pipeline builds, especially after JENKINS-31096 ~ JEP-206: if a non-durable process emits non-ASCII text in some non-UTF‌-8 encoding, it will just be copied as is to the log. The fix would be to make the process launcher perform output trancoding to the charset specified in the TaskListener, assuming the source encoding is the system default on the node running the process (there is no API to specify the encoding in a ProcStarter).

          Not a high priority for Pipeline since most such process executions are things like Git checkouts which are unlikely to include non-ASCII text. Would matter more for freestyle if logs were switched to UTF‌-8, as in JENKINS-48923.

          Jesse Glick added a comment - Likely to be useful for JEP-207 . From code inspection, I suspect that the simplistic treatment of this overload would also produce mojibake under some conditions in Pipeline builds, especially after JENKINS-31096 ~ JEP-206 : if a non-durable process emits non-ASCII text in some non-UTF‌-8 encoding, it will just be copied as is to the log. The fix would be to make the process launcher perform output trancoding to the charset specified in the TaskListener , assuming the source encoding is the system default on the node running the process (there is no API to specify the encoding in a ProcStarter ). Not a high priority for Pipeline since most such process executions are things like Git checkouts which are unlikely to include non-ASCII text. Would matter more for freestyle if logs were switched to UTF‌-8, as in JENKINS-48923 .
          Jesse Glick made changes -
          Link New: This issue relates to JENKINS-31096 [ JENKINS-31096 ]
          Jesse Glick made changes -
          Link New: This issue relates to JENKINS-48923 [ JENKINS-48923 ]
          Jesse Glick made changes -
          Remote Link New: This issue links to "PR 3563 (Web Link)" [ 21231 ]
          Jesse Glick made changes -
          Assignee New: Jesse Glick [ jglick ]
          Jesse Glick made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Jesse Glick made changes -
          Status Original: In Progress [ 3 ] New: In Review [ 10005 ]

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: