master: rollback to previous working version

[tlvu]

I spinned up a Jenkins for @mishaschwartz and I saw the error below. The simplest solution is to revert to the previous working version.

@matprov have you tried to spin up a fresh Jenkins lately?

Current version have this error directly in the WebUI on startup, breaking Jenkins:

io.jenkins.plugins.casc.ConfiguratorException: Invalid configuration elements for type class jenkins.model.GlobalConfigurationCategory$Unclassified : extendedEmailPublisher.
Available attributes : administrativeMonitorsConfiguration, ansiColorBuildWrapper, artifactManager, buildDiscarders, buildStepOperation, casCGlobalConfig, defaultFolderConfiguration, defaultView, email-ext, envInjectNodeProperty, envVarsFilter, fingerprints, ghprbPullRequestMerge, ghprbTrigger, gitHubConfiguration, gitHubPluginConfig, gitSCM, githubPullRequests, globalDefaultFlowDurabilityLevel, globalLibraries, junitTestResultStorage, location, lockableResourcesManager, mailer, masterBuild, myView, nodeProperties, pipeline-model-docker, plugin, pollSCM, projectNamingStrategy, quietPeriod, resourceRoot, scmRetryCount, shell, slackNotifier, subversionSCM, timestamper, usageStatistics, viewsTabBar
    at io.jenkins.plugins.casc.BaseConfigurator.handleUnknown(BaseConfigurator.java:376)
    at io.jenkins.plugins.casc.BaseConfigurator.configure(BaseConfigurator.java:365)
    at io.jenkins.plugins.casc.BaseConfigurator.check(BaseConfigurator.java:287)
    at io.jenkins.plugins.casc.ConfigurationAsCode.lambda$checkWith$8(ConfigurationAsCode.java:755)
    at io.jenkins.plugins.casc.ConfigurationAsCode.invokeWith(ConfigurationAsCode.java:691)
Caused: io.jenkins.plugins.casc.ConfiguratorException: unclassified: error configuring 'unclassified' with class io.jenkins.plugins.casc.impl.configurators.GlobalConfigurationCategoryConfigurator configurator
    at io.jenkins.plugins.casc.ConfigurationAsCode.invokeWith(ConfigurationAsCode.java:697)
    at io.jenkins.plugins.casc.ConfigurationAsCode.checkWith(ConfigurationAsCode.java:755)
    at io.jenkins.plugins.casc.ConfigurationAsCode.configureWith(ConfigurationAsCode.java:740)
    at io.jenkins.plugins.casc.ConfigurationAsCode.configureWith(ConfigurationAsCode.java:616)
    at io.jenkins.plugins.casc.ConfigurationAsCode.configure(ConfigurationAsCode.java:298)
    at io.jenkins.plugins.casc.ConfigurationAsCode.init(ConfigurationAsCode.java:290)
Caused: java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:104)
Caused: java.lang.Error
    at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:110)
    at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:175)
    at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
    at jenkins.model.Jenkins$5.runTask(Jenkins.java:1131)
    at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
    at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
    at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
Caused: org.jvnet.hudson.reactor.ReactorException
    at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:282)
    at jenkins.InitReactorRunner.run(InitReactorRunner.java:50)
    at jenkins.model.Jenkins.executeReactor(Jenkins.java:1164)
    at jenkins.model.Jenkins.<init>(Jenkins.java:964)
    at hudson.model.Hudson.<init>(Hudson.java:85)
    at hudson.model.Hudson.<init>(Hudson.java:81)
    at hudson.WebAppMain$3.run(WebAppMain.java:282)
Caused: hudson.util.HudsonFailedToLoad
    at hudson.WebAppMain$3.run(WebAppMain.java:299)

[tlvu]

@matprov This means if you destroy the jenkins-master container at CRIM, you will not be able to get it back! Better docker save that container somewhere, just in case.

[matprov]

have you tried to spin up a fresh Jenkins lately?

@tlvu I'm not sure about this change, as we currently run pavics/jenkins-master:2.249.1.201009 and not having this particular issue. There are errors in the logs, yes, but not the one you specify here, and not preventing Jenkins from running.

In the past days we also restarted the jenkins containers and haven't had this issue. So I'm not sure that downgrading Jenkins is required. Does Jenkins still runs smoothly even if there is this error?

[tlvu]

have you tried to spin up a fresh Jenkins lately?

@tlvu I'm not sure about this change, as we currently run pavics/jenkins-master:2.249.1.201009 and not having this particular issue. There are errors in the logs, yes, but not the one you specify here, and not preventing Jenkins from running.

In the past days we also restarted the jenkins containers and haven't had this issue. So I'm not sure that downgrading Jenkins is required. Does Jenkins still runs smoothly even if there is this error?

The problem happens on a fresh Jenkins creation only. If you already have an existing working instance, it'll continue to work as long as you do not destroy the container (restarting the container is fine).

I think if you destroy the container and want restart fresh, then this problem will arise.

Try to spin up a brand new instance of Jenkins see if you can reproduce the problem.

[tlvu]

@matprov Just to be clear, I am not suggesting you downgrade your working Jenkins instance. If it works fine, don't touch it (don't pull this change once it is merged).

But better do a docker save of that working jenkins-master container, just in case.

This change is for newcomer to the project to have a working setup.

That error is not in the logs but directly on the WebUI of Jenkins, completely breaking Jenkins.

[matprov]

@tlvu Have you tried to remove the extendedEmailPublisher config param?

[tlvu]

@tlvu Have you tried to remove the extendedEmailPublisher config param?

Humm I can try that another day but I remember we should not have to play with the default params before. I suspect the newer jenkins-master is not self-contained and fetch newer version of some plugins.

We wanted reproducibility so the jenkins-master should be 100% self-contained and not need to pull missing plugins which then will get different versions depending on when it was started.

[tlvu]

@matprov to avoid you doing an accidental pull of this change to your production deployment, you probably want to create a new branch CRIM and point it the the previous master (d41c96dadf62db603456ba70205015d04f9610c6).