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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

--
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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

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

nicolas de loof-2


Le dim. 20 janv. 2019 à 03:40, martinda <[hidden email]> 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 [hidden email].
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.

--
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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

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

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.

On Sun, Jan 20, 2019 at 1:28 AM nicolas de loof <[hidden email]> wrote:


Le dim. 20 janv. 2019 à 03:40, martinda <[hidden email]> 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 [hidden email].
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.

--
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 [hidden email].
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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4owKG9AypaaUbxZPcGzSxgQ1oe9798D%3Domrg%3Dck5NMi6Aw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

Jesse Glick-4
In reply to this post by martinda
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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1RX4NV1ZYq14dV%3D1cEJRmHD9ZjfC1%3D77FY06_btr-JmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.