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 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 .

          Oleg Nenashev added a comment -

          Resolved in 2.136. Looks like a potential LTS candidate

          Oleg Nenashev added a comment - Resolved in 2.136. Looks like a potential LTS candidate

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

              Created:
              Updated:
              Resolved: