(replies inline) On Tue, 15 May 2018, nicolas de loof wrote:
> 2018-05-15 0:20 GMT+02:00 Liam Newman <[email protected]>: > > > > > Putting all that aside (as that is not the original point of this thread), > > the original suggestion was to include a version field in the CasC YAML. > > You said it would not work because the version would have to take into > > account the core version and versions of all plugins, otherwise it might > > break. Does that mean the CasC YAML could break _any time_ I upgrade any > > component? Doesn't that rather defeats the purpose of CasC? > > > > Yes indeed. CasC doesn't have it's own model, everything is based on actual > java code discovery at runtime. So upgrading core or any plugin is changing > this model. CasC targets reproducibility and immutability use-cases. If you > want to upgrade anything you need to test it before. Testing of changes between plugin versions was something I had great difficulty with for Groovy-scripting-based configuration, which was much more common prior to Configuration as Code. Do you have suggestions for administrators such as myself on how I might validate that my configuration YAML is correct/applies between any core or plugin upgrades? This gets to the underlying concern I had in mind when starting this thread, as an administrator, how will I know that my configuration applies correctly between any core or plugin upgrades? My initial thought was schema-versioning, but I'm certainly open to other suggestions. Cheers -- 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/20180515181926.GB3395%40grape.lasagna.io. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
