This code duplication in two sides of the if statement is undesirable.
Post-release, I need to come back here to introduce a variant of FileCallable that runs on the given FilePath but with InputStream to another FilePath.
Still do it so we capture FilePath.remote (which many JRE methods suppress),
but fix the wrapper Throwable.message to include cause.toString() according to convention.
When we are allowing all callables through, we want to enable remote class loading
(just in case someone is using it legitimately), but continue logging callable issues.
Currently there is no remoting flag to allow remote class loading while logging it.
If we ever decide to develop a compatibility thunk library for these changes to help promote deployment in plugins,
then these classes being a nested type is problematic as they'll fail to load under onld Jenkins
The result of a misunderstanding.
BYPASS_LOG can be deleted by the time we release, and for its temporary purpose, runtime modification is not necessary.
It would just provide so much flexibility that would come in handy for operators.
- One can control this feature from $JENKINS_HOME/groovy.init.d/*.groovy. When these are managed by Chef/puppet,
this make it very clean to apply this as a patch.
- The log file is getting too big and wants to rotate? No problem with quick groovy script from the console
(or from CLI if you need to do the same with 12 masters)
- Shipping the log over to network instead of local file? No problem!
I thought your primary concern of field being unreachable from outside is already addressed via @Restricted(NoExternalUse).
It's faster, it's typed, and failing to use the correct name results in an error, so you know when the flag gets removed.
Making it more friendly for Groovy script.
If a @SlaveToMaster Callable gets sent to the master, and if inside its call() method the code directly/indirectly performs file system access (for example on files and directories that it didn't receive as parameters), that is not meant to be the subject of the filter check.
Rather, the check is meant for FilePath that the other side sends to us, when it points to a local file.
So it makes more sense to compute the effective FilePathFilter during the deserialization, as opposed to doing so when the actual operation is attempted.
Various FileCallable impls in FilePath fits this pattern, as it drags outer FilePath instance with itself. In addition, this change addresses other situations correctly, where FilePath is used as arguments and return values of other Callables, such as the following:
FilePath f = channel.call(new SlaveWillDoSomeComputationAndGiveMeTheResultAsFile());
f.copyTo(build.getRootDir().child("data.xml"))
"f.copyTo" happens in the context of Channel.current()==null, but we need to check that 'f' is legit and not something like
new FilePath(new File("/etc/shadow"))
Kohsuke Kawaguchi