Derive URL from sent data
Steffen Schwigon
When I know the data I submit to codespeed, can I create an URL in
advance where this particular commit can be viewed?
Currently URLs seem to use internal IDs which I can't know from outside.
The use-case is: I also send the benchmark data to a Tapper instance and
want to embed a link to the respective codespeed entry.
If not possible, what would need to be done?
Probably one could just map incoming parameters that are not numbers to
actual numbers with a db query.
Kind regards,
Steffen
--
Steffen Schwigon <s...@renormalist.net>
Reiner
I've been thinking about this too. Environments used to be identified
by their name, this was changed to their primary key. There is also
another ticket to do the same with revisions. The reason was, that
environment names can change, and therefore render old links unusable.
Revision commit ids cannot be considered unique, they may be in
multiple branches, so more data has to be passed to identify them
correctly.
Do you need to know this in advance? a8 has been working on a restful
API [1], if you're creating a new benchmark result, it should (at
least that's what I would expect from REST) return a URL to the entry.
Or are you talking about the entry in the admin interface? Could you
provide an example?
Regards,
Reiner
Frank Becker
Hi,
> Do you need to know this in advance? a8 has been working on a restful
> API [1], if you're creating a new benchmark result, it should (at
> least that's what I would expect from REST) return a URL to the entry.
That's what it does.
E.g.:
curl --dump-header - -H "Content-Type: application/json" -X POST \
--data '{"commitid": "7", "branch": "default", "project": \
"MyProject", "executable": "myexe O3 64bits", "benchmark": \
"float", "environment": "Quad Core", "result_value": 4000}'
http://127.0.0.1:8000/api/v1/benchmark-result/
returns:
HTTP/1.0 201 CREATED
Date: Fri, 16 Dec 2011 23:29:10 GMT
Server: WSGIServer/0.1 Python/2.7.1
Content-Type: text/html; charset=utf-8
Location: http://127.0.0.1:8000/api/v1/benchmark-result/15/
15 is the id of the created Result object.
To check that:
curl --dump-header - -X GET http://127.0.0.1:8000/api/v1/result/15/
HTTP/1.0 200 OK
Date: Fri, 16 Dec 2011 23:34:34 GMT
Server: WSGIServer/0.1 Python/2.7.1
Content-Type: application/json; charset=utf-8
returns:
{"date": "2011-12-16T17:29:10.938446", "id": "15", "resource_uri":
"/api/v1/result/15/", "std_dev": null, "val_max": null, "val_min": null,
"value": 4000.0}
Note, the database relations are not implemented by default. That
can be done if required.
Bye,
Frank
--
Frank Becker <f...@alien8.de> (jabber|mail) | http://twitter.com/41i3n8
GnuPG: 0xADC29ECD | F01B 5E9C 1D09 981B 5B40 50D3 C80F 7459 ADC2 9ECD
Steffen Schwigon
And are these URLs (/api/v1/result/15) some that can later be “clicked”
in a browser and give me the typical commit detail page?
Steffen Schwigon
>> curl --dump-header - -X GET http://127.0.0.1:8000/api/v1/result/15/
>> HTTP/1.0 200 OK
>> Date: Fri, 16 Dec 2011 23:34:34 GMT
>> Server: WSGIServer/0.1 Python/2.7.1
>> Content-Type: application/json; charset=utf-8
>>
>> returns:
>>
>> {"date": "2011-12-16T17:29:10.938446", "id": "15", "resource_uri":
>> "/api/v1/result/15/", "std_dev": null, "val_max": null, "val_min": null,
>> "value": 4000.0}
>
> And are these URLs (/api/v1/result/15) some that can later be “clicked”
> in a browser and give me the typical commit detail page?
Ok, I should read the written word. Obviously the URLs return data. So
they are not the ones to be clicked. That's probably not the solution
for my issue.
Steffen Schwigon
> Hi Steffen,
>
> I've been thinking about this too. Environments used to be identified
> by their name, this was changed to their primary key. There is also
> another ticket to do the same with revisions. The reason was, that
> environment names can change, and therefore render old links unusable.
> Revision commit ids cannot be considered unique, they may be in
> multiple branches, so more data has to be passed to identify them
> correctly.
I see and it makes sense.
However, it also sounds like it could be made possible again by probably
just allow both and someone who uses the external names is responsible
for validity by himself.
> Do you need to know this in advance?
In my particular use-case, yes.
> a8 has been working on a restful API [1], if you're creating a new
> benchmark result, it should (at least that's what I would expect from
> REST) return a URL to the entry. Or are you talking about the entry
> in the admin interface? Could you provide an example?
I'm still “finetuning” the vision. Let's see:
I submit my benchmark values as part of a larger test report to a Tapper
instance. Tapper “subscribes” to parts of incoming data chunks (the
interesting benchmarks) and passes those chunks through to 3rd party
applications (like a codespeed instance).
Benchmark -> full_report -> Tapper -> benchmark_data -> Codespeed
Such a report is
http://perlformance.net/tapper/reports/id/838
I now want to augment those incoming reports with more meta information,
for example something similar to the “ticket_url” in this report:
http://perlformance.net/tapper/reports/id/42
This would allow to view the test reports in Tapper and link to
respective codespeed URL.
But this meta data is created in advance by the test+benchmark suite and
embedded into it's report *before* it hits Tapper and Codespeed.
I could imagine the Tapper “pass-through” could augment the report
instead of the testsuite but still I need to forecast the resulting URL
from outside of Codespeed. If that's what the REST api could provide, I
could use it, yes…
Frank Becker
On 18.12.2011, at 00:40, Steffen Schwigon wrote:
Hi,
> Reiner <mr.s...@googlemail.com> writes:
>> Hi Steffen,
>>
>> I've been thinking about this too. Environments used to be identified
>> by their name, this was changed to their primary key. There is also
>> another ticket to do the same with revisions. The reason was, that
>> environment names can change, and therefore render old links unusable.
>> Revision commit ids cannot be considered unique, they may be in
>> multiple branches, so more data has to be passed to identify them
>> correctly.
>
> I see and it makes sense.
>
> However, it also sounds like it could be made possible again by probably
> just allow both and someone who uses the external names is responsible
> for validity by himself.
All the information one has to provide to upload a result value can
be used to query that result value. Sure, in that combination they
are unique. Not sure if it makes sense, though. With the REST api
you get the id of the result. Using that id one can fetch the result
data set by a GET request.
>
> I'm still “finetuning” the vision. Let's see:
>
> I submit my benchmark values as part of a larger test report to a Tapper
> instance. Tapper “subscribes” to parts of incoming data chunks (the
> interesting benchmarks) and passes those chunks through to 3rd party
> applications (like a codespeed instance).
>
> Benchmark -> full_report -> Tapper -> benchmark_data -> Codespeed
So the thing that submits the result data to Codespeed will get the
result id in return. Why not saving that for further reference?
> This would allow to view the test reports in Tapper and link to
> respective codespeed URL.
Right, using the result id you can fetch the data set and inject it
into some web page.
> But this meta data is created in advance by the test+benchmark suite and
> embedded into it's report *before* it hits Tapper and Codespeed.
Hmm, probably I'm a little lost here.
> I could imagine the Tapper “pass-through” could augment the report
> instead of the testsuite but still I need to forecast the resulting URL
> from outside of Codespeed. If that's what the REST api could provide, I
> could use it, yes…
That sounds like you want to generate an url to something that will be there
in the future? Again, while you upload the result data to Codespeed you
get the result id. Using that id you get the full data set back in JSON.