QA (public) » openQA Project (public)

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.

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.

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!

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.

@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

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/ ?

@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 :-)

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.