Error handling in Groovy initialization scripts vs JCasC

[Basil Crow]

After all these years, we finally migrated from Groovy initialization
scripts to JCasC on our Jenkins controllers.

While any configuration error is a problem, I noticed that the way
these errors are reported differs from one mechanism to the next. With
Groovy initialization scripts, errors in one initialization script are
logged but this does not prevent subsequent initialization scripts
from running and startup from completing. In contrast, an error in a
JCasC configuation file causes subsequent changes not to be applied
and halts Jenkins startup.

Do others view this lack of consistency as a problem? If so, would we
want to resolve the inconsistency by making JCasC more lenient or by
making Groovy initialization scripts more draconian? I could see
arguments both ways: making things more draconian is likely to break
things for someone out there, while making things more lenient is
likely to hide legitimate errors and decrease operability. I could
also see an argument for maintaining the status quo if people are
happy with it. If there is a consensus about this I could look into
implementing the change.

[Ullrich Hafner]

From a user experience view I think that the error handling of JCasC currently should be changed (and improved). I’m not using Groovy scripts so I don’t care about consistency in that context. But I think that no application should totally break because of a misconfigured configuration value. This is a very bad user experience (actually I don’t know of any other application that does not start because of a configuration error). I often have this problem that my working JCasC configuration suddenly breaks after an upgrade of JCasC (or another plugin) and Jenkins just not starts up. And then you need to dig into log files to see what happens. It would be much better if those errors would be reported in the UI and the rest of the configuration will be applied (and the broken configuration will be initialized with default values). This is also the approach that we are using if a plugin changes serialization (or if a plugin cannot be started because of missing dependencies): in this case Jenkins still continues to work and the problems are highlighted in the UI. The broken components are just disabled or default values are used.

[Antonio Muñiz]

Cf. https://github.com/jenkinsci/configuration-as-code-plugin/issues/912

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CCA1297B-34F4-4D7E-93C1-65D70AA7B7A2%40gmail.com.

--

Antonio Muñiz

Human, Engineer
CloudBees, Inc.

[Basil Crow]

On Thu, Jun 24, 2021 at 2:18 AM Ullrich Hafner <ullrich...@gmail.com> wrote:
> This is a very bad user experience (actually I don’t know of any other application that does not start because of a configuration error).

I concur. My initial impression is that JCasC lacks polish, and I was
surprised to see it promoted so heavily when issues like this remain.

> This is also the approach that we are using if a plugin changes serialization (or if a plugin cannot be started because of missing dependencies): in this case Jenkins still continues to work and the problems are highlighted in the UI.

Core isn't entirely consistent in this regard, either. Yes
OldDataMonitor and PluginWrapperAdministrativeMonitor exist. But I
just tried corrupting core's config.xml file and Jenkins wouldn't
start at all. But when I corrupted Email Extension's
hudson.plugins.emailext.ExtendedEmailPublisher.xml, Jenkins started
but with the default values for Email Extension and no administrative
monitor in the UI. The latter clearly could use some improvement, but
I'm not sure about the former. It seems that we want _some_
configuration loading errors to be fatal. But which ones, exactly? In
the JCasC issue on GitHub, Antonio raised the valid point that errors
in loading security-related configuration should be fatal (for obvious
reasons).

[Tim Jacomb]

There are some flags you can use to tune this behaviour:

https://github.com/jenkinsci/configuration-as-code-plugin/blob/a6983ff60e0cf198ce02d7992bcba927197174db/test-harness/src/test/resources/io/jenkins/plugins/casc/validSelfConfig.yml#L1-L5

The default is to show an error page with what failed.

> I concur. My initial impression is that JCasC lacks polish, and I was

> surprised to see it promoted so heavily when issues like this remain.

I think the consensus has been it's 'good enough', there's plenty of room for improvement, but in general it works 'just fine' for most use-cases

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjrLf3jJ-dTk%2BOX1E4b2%3DvB2rsWDFgMX0%2BzKNHMbcgRcJA%40mail.gmail.com.

[Gavin Mogan]

I've had times when those groovy scripts "silently" fail on startup, and while isn't a big deal when I'm just restarting an existing instance, it does suck when I'm spinning up a new instance and suddely I don't have security setup.

I used to pair my jcasc config with my jenkins docker image, so I could roll back when things fail to start (I hit a helm bug and had to split them up again). I like the idea in that case of not being able to spin up a broken install. But I also understand that lots of people just tweak existing installs, and probably want warnings without fatals for parsing. So I really like that override behavior. I don't think the default should be warn though since it could potentially lead to insecure setups.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidoM3VfGS%2B4hiMs5dncaVywyrVm7OMt%3DZN6Yj%2BCTDwCyA%40mail.gmail.com.

[Basil Crow]

On Thu, Jun 24, 2021 at 9:07 AM Tim Jacomb <timja...@gmail.com> wrote:
>
> There are some flags you can use to tune this behaviour:
> https://github.com/jenkinsci/configuration-as-code-plugin/blob/a6983ff60e0cf198ce02d7992bcba927197174db/test-harness/src/test/resources/io/jenkins/plugins/casc/validSelfConfig.yml#L1-L5

Those flags don't work in all cases. Try the following JCasC YAML file
when Theme Manager is installed but Dark Theme is not installed:

configuration-as-code:
version: 1
deprecated: warn
restricted: warn
unknown: warn

unclassified:
themeManager:
disableUserThemes: false
theme: "darkSystem"

Jenkins will not start up.

Now try starting Jenkins with a
io.jenkins.plugins.thememanager.ThemeManagerPageDecorator.xml file
that references
io.jenkins.plugins.darktheme.DarkThemeSystemManagerFactory when Theme
Manager is installed but Dark Theme is not installed. Jenkins does
start up. (No warning is displayed and the default theme is used.)

I think the ideal behavior in both cases would be for Jenkins to start
up and display an administrative monitor warning that invalid
configuration was not applied. (Obviously, this would not apply to
security-related configuration per Antonio's point.)

> I think the consensus has been it's 'good enough', there's plenty of room for improvement, but in general it works 'just fine' for most use-cases

I don't disagree. Yet I also recall listening to an interview with
Kohsuke where he explicitly talked about wanting to build a tool that
was not only good enough but also a pleasure to use. That seems like
an example worth following.

[Jesse Glick]

On Thu, Jun 24, 2021 at 5:18 AM Ullrich Hafner <ullrich...@gmail.com> wrote:

I often have this problem that my working JCasC configuration suddenly breaks after an upgrade of JCasC (or another plugin) and Jenkins just not starts up. And then you need to dig into log files to see what happens. It would be much better if those errors would be reported in the UI

Maybe it depends on how you are using JCasC. If you treat your JCasC YAML plus a pinned set of versions of Jenkins core and plugins as an atomic configuration set describing your whole system, with a PR-type workflow, then failing fast is a feature not a bug: if either a change to YAML or a change to some component version causes a failure, then you can clearly see that this is a bad PR and it should not be merged until the issue is resolved.