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

[jglick]

See JENKINS-52729.

I suspect there is also a lower-priority encoding bug here, but I am not bothering with that for now.

Proposed changelog entries

• Developer: Launcher.ProcStarter.stdout(TaskListener) did not properly send its argument over a Remoting channel to an agent.

[jglick]

Sigh, apparently echo is not an actual command on Windows, but built into cmd.exe? Presumably so you can @echo off. Whereas on Linux it is both. Will fix test accordingly.

[jglick]

FTR this call seems to be what would be used by typical freestyle build steps.

[oleg-nenashev]

Yes, it would be nice to get it fixed in the context of External Logging stories. In #3557 reference impls I work it around by creating my own Launcher, but such approach would be much better

[oleg-nenashev]

It makes sense to explicitly set the requirement that the class is remotable in Javadoc

[jglick]

All TaskListener implementations are expected to be remotable but I will clarify this in Javadoc.

[oleg-nenashev]

By the way, stederr() has identical problem. I suggest fixing it here as well so that we do not get into surprises with some implementations really using 2 streams

[oleg-nenashev]

OTOH we could create a follow-up task for stederr

[jglick]

stderr() has identical problem. I suggest fixing it here as well

It does not—there is no stderr(TaskListener) overload. If we wished to allow a distinct and remotable stderr stream, that would be a new API which plugins would have to call.

surprises with some implementations really using 2 streams

The implementations we care about (CommandInterpreter, SCM plugins, etc.) do not separate stderr. I cannot find any callers using this method from a brief search.

There are some calls which currently call stdout(OutputStream) which would not benefit from this change, such as Maven.perform, but that is out of scope.

I did find one possible bug in the mercurial plugin: if you call stdout(TaskListener) and then stdout(OutputStream) you expect the latter call to cancel the former.

[jglick]

Test failure is a common flake:

java.lang.AssertionError: deletion stopped
	at org.junit.Assert.fail(Assert.java:88)
	at org.junit.Assert.assertTrue(Assert.java:41)
	at org.junit.Assert.assertFalse(Assert.java:64)
	at hudson.UtilTest.testDeleteRecursive_onWindows(UtilTest.java:489)

[oleg-nenashev]

OK, let's merge it as is. Public API does not change here, so we can fix STDERR in a follow-up if I discover the usa-case for it