Re: Error handling in Groovy initialization scripts vs JCasC

[Jesse Glick]

On Thu, Jun 24, 2021 at 5:18 AM Ullrich Hafner 
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.

-- 
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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0JbtH9JPz-sq8Enpd-kxXZbEoGQpHzf5giMX4%3D3%2B8TGw%40mail.gmail.com.

Re: Error handling in Groovy initialization scripts vs JCasC

[Basil Crow]

On Thu, Jun 24, 2021 at 9:07 AM Tim Jacomb  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.

-- 
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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjqSK-xxwCgTeOCKrviU2JSnce9OkXURcgtvURzMFf3Rag%40mail.gmail.com.

Re: Error handling in Groovy initialization scripts vs JCasC

['Gavin Mogan' via Jenkins Developers]

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.

On Thu, Jun 24, 2021 at 9:08 AM Tim Jacomb  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
>
> 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
>
>
>
> On Thu, 24 Jun 2021 at 16:54, Basil Crow  wrote:
>
>> On Thu, Jun 24, 2021 at 2:18 AM Ullrich Hafner 
>> 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).
>>
>> --
>> 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-dev+unsubscr...@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
>> .
>>
> --
> 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-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidoM3VfGS%2B4hiMs5dncaVywyrVm7OMt%3DZN6Yj%2BCTDwCyA%40mail.gmail.com
> 
> .
>

-- 
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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_Duvc4Ai%3D6PXbkTXgOkH4K%2BOU7FbLT5ZE7UR9Y%3Dzymxp%2Byw%40mail.gmail.com.

Re: Error handling in Groovy initialization scripts vs JCasC

[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



On Thu, 24 Jun 2021 at 16:54, Basil Crow  wrote:

> On Thu, Jun 24, 2021 at 2:18 AM Ullrich Hafner 
> 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).
>
> --
> 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-dev+unsubscr...@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
> .
>

-- 
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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidoM3VfGS%2B4hiMs5dncaVywyrVm7OMt%3DZN6Yj%2BCTDwCyA%40mail.gmail.com.

Re: Error handling in Groovy initialization scripts vs JCasC

[Basil Crow]

On Thu, Jun 24, 2021 at 2:18 AM Ullrich Hafner  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).

-- 
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-dev+unsubscr...@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.

Re: Error handling in Groovy initialization scripts vs JCasC

[Antonio Muñiz]

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

On Thu, 24 Jun 2021 at 11:18, Ullrich Hafner 
wrote:

>
>
> > Am 24.06.2021 um 00:54 schrieb 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.
>
>
> 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 jenkinsci-dev+unsubscr...@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.

-- 
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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAJc7kzTfr7QumVupqzzbZG23E0X_FWq5aqNozGKaHSu96jHOYw%40mail.gmail.com.

Re: Error handling in Groovy initialization scripts vs JCasC

[Ullrich Hafner]

> Am 24.06.2021 um 00:54 schrieb 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.


>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 jenkinsci-dev+unsubscr...@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.