Hello, There is a GSoC proposal on automatically generating the Jenkins REST API <https://docs.google.com/document/d/1CYzV_w5SrA-npXEMwTkJ4E2QyJdd2cJm7eDpwhg4XPk> for core and plugins, from a REST API spec generator like OpenAPI. I can kind of see this as being possible for future plugins, but for all the existing code it would be a difficult exercise in extracting the spec from annotations, source code, and javadocs.
I am trying to clarify the GSoC proposal, and frame it in way that some kind of progress can be made. Would anyone have a suggestion here? There has been an effort in that direction by Cliffano with swaggy-jenkins. Cliffano told me that he reversed engineered the the response model definition from the HTTP response payload, because in early 2017 there might have been an effort to move to GraphQL instead of REST. I wonder if this is still relevant and how it could affect the GSoC proposal. I also found a closed PR on stapler <https://github.com/stapler/stapler/pull/121> to make stapler more declarative, and I wonder if this could lead in some way towards automatic REST API generation. Is that PR something a potential GSoC student could take on? Best, Martin d'Anjou Jenkins GSoC Org Admin Team -- 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/2b14b028-1bae-4400-abcf-544cf5669cb7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
