Cf. https://github.com/jenkinsci/configuration-as-code-plugin/issues/912
On Thu, 24 Jun 2021 at 11:18, Ullrich Hafner <[email protected]> wrote: > > > > 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 > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAJc7kzTfr7QumVupqzzbZG23E0X_FWq5aqNozGKaHSu96jHOYw%40mail.gmail.com.
