> Am 24.06.2021 um 00:54 schrieb Basil Crow <[email protected]>:
>
> 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.
>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.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CCA1297B-34F4-4D7E-93C1-65D70AA7B7A2%40gmail.com.
