action #14580

Add ability to backup selected jobs/tests results outside of o.s.d/o.o.o

Added by mimi_vx over 3 years ago. Updated almost 2 years ago.

Status:ResolvedStart date:31/10/2016
Priority:HighDue date:
Assignee:szarate% Done:

90%

Category:Feature requests
Target version:Done
Difficulty:
Duration:

Description

For QAM is important to store results from test for whole lifetime of product. Outside of openQA instance.
Wee need run some internal tools over results.


Related issues

Related to openQA Project - action #27955: Allow the worker_bridge to sync job status from a slaveUI... Rejected 20/11/2017
Related to openQA Project - action #10316: [epic] Better command line options extending "client" In Progress 27/03/2018

History

#1 Updated by okurz over 3 years ago

  • Category set to Feature requests

You may want to use https://progress.opensuse.org/projects/openqav3/wiki#feature-requests as a template for this feature request. Can you state which part of test results of a job you want to backup? I am not sure if this needs any changes on openQA side. You can access job results over webui as well as API which should give all the necessary information, e.g. try curl -s https://openqa.opensuse.org/api/v1/jobs/234123 to have results in JSON. Try https://openqa.opensuse.org/help to see all available routes.
Probably a script on your side is a better solution here.

#2 Updated by RBrownSUSE over 3 years ago

Oli, your Template is not an approved process by the openQA community, nor approved by either of the project leads (Coolo and myself)

Please remove the wiki article, or at less stop demanding people use a process which you concocted on your own

Consider people's feature requests on THIER own merits, not just your own criteria.

#3 Updated by okurz over 3 years ago

As far as I remember I showed you the wiki section and asked for your approval but I might be wrong. I did not demand to use the template but offered it as an idea as well as trying to give helpful questions and ideas.

#4 Updated by rdodopoulos about 3 years ago

okurz, I tried curl https://openqa.opensuse.org/api/v1/jobs/653953 to retrieve the job results over API but it doesn't work. Has the command changed since 1 month ago? Thanks!

#5 Updated by pgeorgiadis about 3 years ago

I've never tried the API way. In any case, feel free to use https://github.com/drpaneas/dbaq for fetching the results + parsing them.

#6 Updated by coolo about 3 years ago

@rdodopoulos - it helps if the instance you're fetching the job from actually has that job. openqa.opensuse.org's max job id is 313196

#7 Updated by rdodopoulos about 3 years ago

coolo wrote:

@rdodopoulos - it helps if the instance you're fetching the job from actually has that job. openqa.opensuse.org's max job id is 313196

I thought it could predict future results but I guess not :(

Well, https://openqa.suse.de/api/v1/jobs/653953/ returns the settings instead of the results. Is there something that can provide the results in a way that Panos' dbaq does? If not, should we include his script in os-autoinst/openQA/scipt/ ?

#8 Updated by okurz about 3 years ago

@rdodopoulos I think dbaq provides a nice way to access the data. The api provides another. Both way can not provide everything that the database of openQA knows about the job including all screenshots, logs, relations, settings, etc. There was the idea to provide a more or less full representation of the jobs result page in json but we don't have that yet. I am not sure what you want to achieve and what data exactly is necessary for that. Also for this ticket the use case is unclear to me (hence comment #1 which was apparently misunderstood) and there is no progress. I think dbaq should stay in it's own repository as it is a client tool which interacts with openQA but does not need to be developed in the same repository with it. You might also try other options - depending on your specific needs - e.g. openQA-python-client and openqa_review. The latter is also in openSUSE Tumbleweed and Leap 42.2, a simple zypper in python-openqa_review away :-)

#9 Updated by coolo over 2 years ago

  • Priority changed from Normal to High
  • Target version set to Ready

This sounds like a low hanging fruit with the federation

#10 Updated by szarate over 2 years ago

  • Related to action #27955: Allow the worker_bridge to sync job status from a slaveUI to a masterUI added

#11 Updated by szarate about 2 years ago

  • Target version changed from Ready to Current Sprint

#12 Updated by szarate about 2 years ago

  • Status changed from New to In Progress

I'm picking this one, basically I'm adding --archive functionality to the openqa client

#13 Updated by szarate about 2 years ago

  • Related to action #10316: [epic] Better command line options extending "client" added

#14 Updated by szarate about 2 years ago

  • Assignee set to szarate

#15 Updated by szarate almost 2 years ago

There is a PR: https://github.com/os-autoinst/openQA/pull/1571

Currently there is a problem addressing a request of making the download of assets an opt-in with a size limit.

When setting max_size_message in the UA, it works if the file is above 128K but otherwise if max_message_size is set under under that, it seems to fail in my local branch.

#16 Updated by szarate almost 2 years ago

  • % Done changed from 0 to 90

PR has been updated and WIP label removed.

#17 Updated by szarate almost 2 years ago

  • Status changed from In Progress to Feedback

Setting this to feedback for now :) As there are no more comments on the PR.

#18 Updated by szarate almost 2 years ago

  • Status changed from Feedback to Resolved

#19 Updated by szarate almost 2 years ago

  • Target version changed from Current Sprint to Done

Also available in: Atom PDF