GSoC proposal on OpenAPI REST API spec generator for Jenkins core and plugins

[martinda]

Hello,

There is a GSoC proposal on automatically generating the Jenkins REST API 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 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

[nicolas de loof]

Le dim. 20 janv. 2019 à 03:40, martinda <martin....@gmail.com> a écrit :

Hello,

There is a GSoC proposal on automatically generating the Jenkins REST API 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.

This is exactly what Configuration as code is doing, so you could reuse this mechanism (or better: get this natively supported by stapler)

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 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-de...@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.

[Matt Sicker]

I made a feature request for this upstream: https://github.com/stapler/stapler/issues/139

Without the declarative annotations defined everywhere, it'd be somewhat difficult to only export explicitly exported APIs. Instead, some approach similar to how dispatching is handled would need to be used to generate the API graph.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzkLx89JpJVbghxqPCK9f9pd-1BZOiPJk_H3g4tDhZ7WWw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Matt Sicker

Software Engineer, CloudBees

[Jesse Glick]

FYI there was also an effort to define a fresher API, but I am not
sure of its status. Initially was a proto-JEP:

https://github.com/amuniz/jep/pull/1

and moved into some prototyping:

https://github.com/jenkinsci/jenkins/compare/data-api