GlobalConfiguration.all() throws IllegalStateException

[Carles Capdevila Tejada]

Hi there,

We're running into an issue at the Log File Filter plugin, which uses the GlobalConfiguration class to manage its configuration:

Jan 29, 2019 9:34:08 AM org.jenkinsci.plugins.workflow.log.TaskListenerDecorator$DecoratedTaskListener getLogger
WARNING: null
java.lang.IllegalStateException: Jenkins.instance is missing. Read the documentation of Jenkins.getInstanceOrNull to see what you are doing wrong.
        at jenkins.model.Jenkins.get(Jenkins.java:758)
        at jenkins.model.GlobalConfiguration.all(GlobalConfiguration.java:75)
        at com.tsystems.sbs.LogFileFilterConfig.get(LogFileFilterConfig.java:27)
        at com.tsystems.sbs.LogFileFilterOutputStream.<init>(LogFileFilterOutputStream.java:42)
        at com.tsystems.sbs.LogFileFilterConsoleLogFilter.decorateLogger(LogFileFilterConsoleLogFilter.java:32)
        at hudson.console.ConsoleLogFilter.decorateLogger(ConsoleLogFilter.java:60)
        at org.jenkinsci.plugins.workflow.steps.BodyInvoker$MergedFilter.decorateLogger(BodyInvoker.java:133)
        at org.jenkinsci.plugins.workflow.steps.BodyInvoker$MergedFilter.decorateLogger(BodyInvoker.java:133)
        at org.jenkinsci.plugins.workflow.steps.BodyInvoker$MergedFilter.decorateLogger(BodyInvoker.java:133)
        at org.jenkinsci.plugins.workflow.log.TaskListenerDecorator$ConsoleLogFilterAdapter.decorate(TaskListenerDecorator.java:205)
        at org.jenkinsci.plugins.workflow.log.TaskListenerDecorator$DecoratedTaskListener.getLogger(TaskListenerDecorator.java:244)
        at org.jenkinsci.plugins.workflow.log.TaskListenerDecorator$CloseableTaskListener.getLogger(TaskListenerDecorator.java:286)
        at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1304)
        at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1266)
        at hudson.remoting.UserRequest.perform(UserRequest.java:212)
        at hudson.remoting.UserRequest.perform(UserRequest.java:54)
        at hudson.remoting.Request$2.run(Request.java:369)
        at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:93)
        at java.lang.Thread.run(Thread.java:748)

This happens when running the plugin's step inside a pipeline job. I've looked at Jenkins.getInstanceOrNull() as it says, but strangely it points out that the problem should be caused by a remoting/JVM issue, and in our case the code isn't running inside a node step.

We're looking for a solution but right now we don't have a clue. Does anybody have any tip?

Thanks!

[Jesse Glick]

On Thu, Jan 31, 2019 at 1:19 PM Carles Capdevila Tejada
<capde...@gmail.com> wrote:
> java.lang.IllegalStateException: Jenkins.instance is missing. Read the documentation of Jenkins.getInstanceOrNull to see what you are doing wrong.
> at jenkins.model.Jenkins.get(Jenkins.java:758)
> at jenkins.model.GlobalConfiguration.all(GlobalConfiguration.java:75)
> at com.tsystems.sbs.LogFileFilterConfig.get(LogFileFilterConfig.java:27)
> at com.tsystems.sbs.LogFileFilterOutputStream.<init>(LogFileFilterOutputStream.java:42)
> at com.tsystems.sbs.LogFileFilterConsoleLogFilter.decorateLogger(LogFileFilterConsoleLogFilter.java:32)
> at hudson.console.ConsoleLogFilter.decorateLogger(ConsoleLogFilter.java:60)

> at …

> at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1304)
> at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1266)
> at hudson.remoting.UserRequest.perform(UserRequest.java:212)

> at …

This is running inside an agent JVM. Thus you may not refer to a
`GlobalConfiguration`, which exists on the master side. Whatever
configuration state you need must be extracted from
`LogFileFilterConfig` when the `LogFileFilterConsoleLogFilter` is
created in the `StepExecution`, and saved in `Serializable` fields.

[Carles Capdevila Tejada]

Thanks for the help Jesse! Though I thought that pipeline code is always executed in the master,

unless inside of a node() step :/

In the mentioned execution the step is called outside of a node() step, like so:

    logFileFilter () {
            node (nodeLabel) {
                 ...

So shouldn't it be executed on the master?

Thanks!

[Jesse Glick]

On Mon, Feb 4, 2019 at 4:49 AM Carles Capdevila Tejada
<capde...@gmail.com> wrote:
> I thought that pipeline code is always executed in the master

“Pipeline code” is too broad an expression to be meaningful. The
bodies of specific API methods, such as `StepExecution.start` or
`SimpleBuildStep.perform`, are indeed run on the master. But if you
use `Callable` / `FileCallable` then you are requesting the body to
potentially be run on an agent. And `ConsoleLogFilter`s /
`TaskListenerDecorator`s may be run on agents.

> unless inside of a node() step

Running “inside” a `node` block has no effect on where code runs,
except insofar as code which _might_ run on an agent _could not_ even
start if you were not inside a `node` block. (Typically seen by the
engine refusing to run a step, throwing
`MissingContextVariableException`.) The `node` block merely offers a
contextual `FilePath`, `Computer`, etc. for any code which might ask
for it via `StepContext.get`.

> In the mentioned execution the step is called outside of a node() step, like so:
>
> logFileFilter () {
> node (nodeLabel) {
> ...
>
> So shouldn't it be executed on the master?

No, because the `sh` step inside `node` remotes a `TaskListener` to an
agent whose serial state includes your `ConsoleLogFilter`.

[Carles Capdevila Tejada]

Getting the configuration at the StepExecution fixed it, thanks a lot for the help and the revelations!