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

Launcher.ProcStarter.stdout(TaskListener) discards remotability

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: core
    • Labels:
      None
    • Similar Issues:
    • Released As:
      Jenkins 2.136

      Description

      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.

        Attachments

          Issue Links

            Activity

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

            Show
            jglick 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 .
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            Resolved in 2.136. Looks like a potential LTS candidate

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

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: