qa-devel August 2016

qa-devel@lists.fedoraproject.org

4 participants
4 discussions

Resultsdb v2.0 - API docs
by Josef Skladanka 04 Oct '16

04 Oct '16

Hey gang, I spent most of today working on the new API docs for ResultsDB, making use of the even better Apiary.io tool. Before I put even more hours into it, please let me know, whether you think it's fine at all - I'm yet to find a better tool for describing APIs, so I'm definitely biased, but since it's the Documentation, it needs to also be useful. http://docs.resultsdb20.apiary.io/ I am also trying to put more work towards documenting the attributes and the "usual" queries, so please try and think about this aspect of the docs too. Thanks, Joza

4 13

openQA: nother git bump comin'
by Adam Williamson 10 Sep '16

10 Sep '16

Hey folks! Just a heads-up to the openQA-interested: I'm working on another update to current upstream git. staging is now running the latest git of both os-autoinst and openQA. There have been some changes upstream which are related to working with Mojolicious 7, but aaannz assures me they're Mojo 6-compatible, and they still have one deployment running on Mojo 6. So far, it seems to be working OK. We're slightly suspicious about https://github.com/os-autoinst/openQA/commit/f2547e9bcc0a166f993426bceeacd0… ; apparently they're still arguing about whether it's the right thing to do. I'll keep an eye on it, and if any uploads go squiffy, I'll revert it in the package. So far, though, at least one upload test has run and worked. One nice thing about this git bump is it disables the extremely verbose myjsonrpc logging which was going on and making the logs quite difficult to read and follow. If any of you want to play along with your pet deployments, the scratch builds are here: http://koji.fedoraproject.org/koji/taskinfo?taskID=15391589 http://koji.fedoraproject.org/koji/taskinfo?taskID=15391751 if this runs OK in staging for the next day or two I'll do official builds and submit an F24 update, then bump prod later next week. One significant change with the new openQA is they've changed how 'softfails' work. Previously, it wasn't a 'real' result - tests could only be 'passed' or 'failed' as a whole, the concept of a 'soft failure' was kind of synthesized by the web UI based on the individual test module results, but wasn't expressed by the API, the API 'result' for soft failed tests was just 'passed'. If you wanted to catch soft fails you had to parse the test module results and replicate the logic the web UI used. Now, 'softfailed' is simply a result state; both a test as a whole and individual test modules can have 'softfailed' as their result. For now, I've patched everything we have that considers openQA results (that's fedora_openqa_schedule, fedora_nightlies, and check-compose) to treat 'softfailed' the same as 'passed' (except check-compose, which does distinguish between passes and soft fails). In future, we could get more clever with this, and maybe report 'warn' rather than 'pass' to the wiki for soft fails, that kinda thing. But for now this should preserve current behaviour. Most of the changes I could just commit, only one requires review: https://phab.qadevel.cloud.fedoraproject.org/D987 BTW, in case any of you were trying to do needle edits using interactive mode and being annoyed that when a needle match fails and you go to the editor, you can't use any existing needle as a base for the new one, it's a known bug in the recent interactive mode rewrite, unfortunately without a fix for now: https://progress.opensuse.org/issues/13456 https://progress.opensuse.org/issues/12680 I'm hoping coolo will show up with a fix next week. If they don't fix it soon I might try, because it's a really annoying bug, but this is kind of a complex area to grok and be sure you're fixing it right, I think it'll be much easier for coolo to do since he already understands exactly how all the bits are interacting there. For now my 'workaround' is to hack up the post_fail_hook to do nothing (so you don't have to wait around for a bunch of log uploads every time the test fails) then just keep re-running the test, waiting for it to fail, and editing the failed needle, until they're all done. The editor works properly when you use it on a failed test (as opposed to an interactive test that's paused and waiting for the needle editor). Thanks folks!

1 2

"500 Internal Server Error" when trying to submit a new blocker bug
by Christian Stadelmann 29 Aug '16

29 Aug '16

Whenever I'm trying to submit a new blocker bug¹, I'm getting a HTTP 500 status code error page. I've tried these browsers: * one recent release of Firefox (heavily configured) * one vanilla Fedora Firefox release * one Firefox LTS based release With all of these I'm getting the error page and am unable to propose blocker bugs as a result. I remember that this worked on the last release cycle, I think I proposed some F24 blocker bugs. ¹ https://qa.fedoraproject.org/blockerbugs/propose_bug If I could propose blocker bugs, I'd propose these ones as Final blockers: * https://bugzilla.redhat.com/show_bug.cgi?id=1026119 Title: "fails to unmount encrypted filesystem (/dev/mapper/luks-partition) containing /var/log on every shutdown" Reason: This bug violates the final release criterion "Shutdown, reboot, logout": "Similar to the Alpha criterion for shutting down, shutdown and reboot mechanisms must take storage volumes down cleanly and correctly request a shutdown or reboot from the system firmware." There is no clean shutdown here. * https://bugzilla.redhat.com/show_bug.cgi?id=1370889 Reason: gnome-weather is completely broken due to backend service URL change or shutdown. This violates section "Default application functionality" of Fedora final release criteria: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test. […]" Basic functionality of gnome-weather includes showing weather for at least one user-selected location, which is not working right now.

2 3

libtaskotron: new mock needed to run the test suite
by Kamil Paral 22 Aug '16

22 Aug '16

Please note I've bumped the requirements for mock in libtaskotron and removed some workarounds we had for bugs in the older version. Please make sure to run $ git pull $ pip install -r requirements.txt otherwise the test suite might not pass for you the next time you run it and the errors are very cryptic. Cheers, Kamil

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

qa-devel August 2016