It’ll be a while before we’ll be able to publish what we want to demonstrate (this goes beyond just the Jenkins YAML file, there are surrounding components that make up our in-house ‘Jenkins on AWS’ template). But any solution would have to generate the YAML file as a starting point, so in the meantime you could get started with something that does that.
The configurations of plugins are at least somewhat discoverable already. Some random thoughts on it… - Plugin configuration is marked with @Extension (and often extends GlobalConfiguration), which allows config scanners inside Jenkins to find it. - Jenkins Extensions Index (https://jenkins.io/doc/developer/extensions/ <https://jenkins.io/doc/developer/extensions/>) is an auto-generated site that lists all API extension points, and known implementations. My guess is that the generator is somehow scraping the plugins hosted under the jenkinsci GitHub org. This might be more of interest, because you’re probably looking to get information from the plugins without actually running Jenkins. - The configuration-as-code-plugin can both serialise and parse CasC YAML. To try this, just install configuration-as-code-plugin on your server, then navigate to /configuration-as-code, and hit the button that serialises the active configuration as YAML. (Though do note the caveat that it may not be totally accurate.) Finally, note that some plugins have a different model for CasC-received config than the standard one they use for Web UI-received config. This allows them to present a cleaner config model to CasC users than what the Web UI would normally allow. The translation is done in a class that looks like this... public class PluginRootConfigurator extends BaseConfigurator<T> implements RootElementConfigurator<T> { public Set<Attribute<T,?>> describe() { // All the translation happens here } } Where T is the plugin’s standard configuration class, that is exposed to the Web UI. Chris > On 2 Mar 2020, at 18:46, Sladyn Nunes <[email protected]> wrote: > > Chris any luck with the sharing of the yaml file for AWS ? If no, then +Rick > and +Jeff would we just stick with the basic packager configuration file that > I mentioned in my previous message, which would include only the version > artifact and the plugin. > Because on putting further thoughts into it, would it not be difficult to > represent all the configurations into the User Interface, because every > plugin has so many options, I am not sure if there is an automatic way to > grab onto the configurations of every plugin ? > > On Wednesday, January 8, 2020 at 8:19:32 PM UTC+5:30, Rick wrote: > Hi team, > > I'd like to share an idea with you. There are some original discussions from > the GSoC thread > <https://groups.google.com/d/msgid/jenkinsci-gsoc-all-public/36332f60-e8f0-4cc0-a37d-642990c824d9%40googlegroups.com?utm_medium=email&utm_source=footer> > here. > > For many users, they download Jenkins first, then select some plugins and > config them. It might take a lot of time, like hours. But if we can get a > perfect Jenkins distribution which contains all we need, it can save that > time for us. Yes, I propose an out of the box solution. > > The service could be like this, a website offered as > https://customize.jenkins.io <https://customize.jenkins.io/>. Plus, it should > be self-host. People can select the following configurations: > Jenkins core version > plugins > common configuration, user/password, update-center site e.g. > plugin based configuration, Kubernetes, Sonarqube plugin config e.g. > multi-form package, jenkins.war or docker image > other things > Two projects are expected backend and frontend. I think > https://github.com/jenkinsci/custom-war-packager > <https://github.com/jenkinsci/custom-war-packager> already did a lot of > works. We can reuse it in this project. The backend should provide the modern > Restful API. We can start the backend project with SpringBoot, it can save a > lot of time. > > About the frontend project, I don't have too many experiences on it. For > example, we can start it by React framework. If you're instrested in it, > please help to add more ideas on it. > > Any feedbacks are very appreciated. > > Best regards, > Rick > -- > Zhao Xiaojie (Rick) > Blog: https://github.com/LinuxSuRen <https://github.com/LinuxSuRen> > Twitter: https://twitter.com/suren69811254 <https://twitter.com/suren69811254> > > -- > 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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/00a824b5-9dbf-4ae6-8b7d-0307cac3dd17%40googlegroups.com > > <https://groups.google.com/d/msgid/jenkinsci-dev/00a824b5-9dbf-4ae6-8b7d-0307cac3dd17%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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/80B9F0D6-AF5A-4526-A241-DACA807FAC0C%40chriskilding.com.
