[Essentials] Error Telemetry Server API JEP Draft

22 views
Skip to first unread message

Baptiste Mathus

unread,
May 8, 2018, 3:48:02 PM5/8/18
to Jenkins Developers
Hello everyone,

After defining how we would do the client side of error telemetry logging in JEP-304, I just published a draft of the corresponding server side for review:



Feedback welcome. You will notice it's simpler and smaller than the client side one.

As usual, after I made sure there are no clear pushback from the community here, I will file the corresponding PR to get it merged and assigned a JEP number.

Thank you everyone!

-- Baptiste

R. Tyler Croy

unread,
May 10, 2018, 6:54:31 PM5/10/18
to jenkin...@googlegroups.com
(replies inline)

On Tue, 08 May 2018, Baptiste Mathus wrote:

> Hello everyone,
>
> After defining how we would do the client side of error telemetry logging
> in JEP-304 <https://github.com/jenkinsci/jep/tree/master/jep/304>, I just
> published a draft of the corresponding server side for review:
>
> https://github.com/batmat/jep/tree/JENKINS-51140/0000


Woohoo more designs! :)

I have a lot of questions and feedback, and since this is an early stage
design, I thiink it would be more efficient for us to jump on a Google Hangout
tomorrow (Friday).

The biggest gap which I'm sure you've thought about but isn't present in this
design document are the client/server interactions and what are the expected
REST calls/responses. Take a look at this for more of what I'm expecting:
https://github.com/jenkinsci/jep/tree/master/jep/303#specification


Cheers
signature.asc

Baptiste Mathus

unread,
May 11, 2018, 8:49:35 AM5/11/18
to Jenkins Developers
Thanks for the feedback!

Indeed, I had in mind the usual HTTP 201 for creation, and so on for other cases, but definitely this needed to be not just in my mind. That's the whole point.
Also, your challenge here made me rethink and refactor the prototype to avoid sending back the log as it's usually done in REST endpoints, because it seems like a waste when for instance client would be sending 5000 characters or more to just have them transiting back and forth for nothing.

About the authentication/registration, I clarified the intent is to make this endpoint /behind/ what's defined in JEP 303.

Yes, let's meet when you're available, I think that's a good idea. I'm especially interested to hear if you have an opinion about what the response payload should have. 
For instance, as I wrote in a comment in the JEP:

"Should we compute a hash or something to be able to uniquely reference/find a log in the system between client and server if needed?"

-- Baptiste

--
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/20180510225420.GG2935%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.

Baptiste Mathus

unread,
May 15, 2018, 7:57:01 AM5/15/18
to Jenkins Developers
Hello everyone,

For your information, I've now opened a PR to make this proposal a draft.

Cheers!


Reply all
Reply to author
Forward
0 new messages