qa-devel September 2016

qa-devel@lists.fedoraproject.org

11 participants
11 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

What to do with fedora-qa (fedorahosted is dying)
by Adam Williamson 04 Oct '16

04 Oct '16

We still have a few miscellaneous things hosted in: https://git.fedorahosted.org/cgit/fedora-qa.git since fedorahosted is dying next February, what should we do with them? Is this the point where we should finally decide whether to use Phabricator's built-in repository support or Pagure for this stuff and the stuff we currently host on bitbucket? We also still use the fedorahosted *trac* for non-code-related activity tracking, but I guess that's better followed up on test@. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

4 6

RFR: New Dist-Git Task Storage Proposal
by Tim Flink 03 Oct '16

03 Oct '16

I wrote up a quick draft of the new dist-git task storage proposal that was discussed in Brno after Flock. https://phab.qadevel.cloud.fedoraproject.org/w/taskotron/new_distgit_task_s… Please review the document and either let me know (or fix in the wiki page) things which aren't clear or bits that I forgot. Tim

3 6

RFC: URLs for docs and released bits from CI
by Tim Flink 27 Sep '16

27 Sep '16

I submitted a revision today which makes some slight modification to how the doit.py script is building docs, rpms and tarballs. https://phab.qadevel.cloud.fedoraproject.org/D1012 My intention is to get this deployed to a non-staging setup soon but I wanted to reach out to see if anyone had an issue for the URLs that would end up being used. https://baseurl/docs/<projectname> This path would contain docs for <projectname> built per branch for non-master branches and per-release-version when triggered on the master branch. The 'latest' symlink will always be updated to point at the most recent build on the master branch https://baseurl/releases/<projectname> Pretty much the same thing as for docs but with the rpms, srpms and tarball(s) created during the CI build. Does this seem sane to everyone? Any comments/questions/suggestions? I'd like to get the auto-docs functionality deployed soon - hopefully right after F25 beta freeze is over. Tim

3 3

Enabling task-abicheck notification for all maintainers *by default*
by Dodji Seketeli 27 Sep '16

27 Sep '16

Hello fine fellows, There recently was another incompatible ABI change in a core library in Fedora. This did spark a lot of discussions, especially in the thread at https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…. The good news is that incompatible ABI change was caught by our task-abicheck task. The less good news is nobody got aware of the result of the task because the maintainer was most likely not notified. Because by default, notifications about the result of this task are turned off. And another message to the thread I mentionned above shows that it's not that easy to turn those notifications on without making any mistake: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…. I guess my point is that experience is showing us that if this kind of notification is not enabled by default, people are just not aware of it. I am thus proposing that notifications about the results of task-abicheck that are either NEEDS_INSPECTION or FAILED be sent to maintainers of the relevant packages *by default*. There is also a proposal about making Bodhi to block the automatic push of a given build to the stable repository *if* the task-abicheck result for that build is either NEEDS_INSPECTION or FAILED. I obviously agree with this latest proposal, of course. But I think it should come in *addition* to making maintainers aware of (possible) incompatible ABI changes of their packages *early*, at Koji build time, giving them a chance to fix things before they reach the Bodhi stage. What do you think? -- Dodji

2 1

2016-09-12 @ 14:00 UTC - Fedora QA Devel Meeting
by Tim Flink 26 Sep '16

26 Sep '16

# Fedora QA Devel Meeting # Date: 2016-09-26 # Time: 14:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting-1 on irc.freenode.net There are several topics that would benefit from discussion and/or group review during a qadevel meeting this week: https://phab.qadevel.cloud.fedoraproject.org/w/meetings/20160926-fedoraqade… If you have any additional topics, please reply to this thread or add them in the wiki doc. Tim Proposed Agenda =============== Announcements and Information ----------------------------- - Please list announcements or significant information items below so the meeting goes faster Tasking ------- - Does anyone need tasks to do? Potential Other Topics ---------------------- - Docker Testing Status - Trigger Re-Write Status - CI Generated Document URLs - Dist-Git Task Storage Proposal - Packaging Status (Taskotron related, Phabricator, etc.) Open Floor ---------- - TBD

1 1

2016-09-14 @ 14:00 UTC - QA Tools Video "Standup" Meeting
by Tim Flink 22 Sep '16

22 Sep '16

# QA Tools Video "Standup" Meeting # Date: 2016-09-14 # Time: 14:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://bluejeans.com/2509415264 One discussion that came up after Flock was that doing a video meeting would be worth trying to see how it works for us in terms of collaborating. In that vein, we're going to try this and see how well it works. This will be in bluejeans which does require flash and/or plugins to work. I'm not overly tied to it, this is just the easiest option for now :) https://bluejeans.com/2509415264 The agenda is pretty simple: everyone takes a turn saying what they're working on this week and what, if anything, is keeping them from making progress. Hope to see people there. Tim

5 7

Planned Outage: QA systems - 2016-09-21 21:00 UTC
by Tim Flink 19 Sep '16

19 Sep '16

This has been announced through other channels but just to make sure folks are aware, there there will be an outage starting at 2016-09-21 21:00 UTC, which will last approximately 4 hours. This will affect all qa systems (amongst others): - taskotron - phabricator - blockerbugs - openqa To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2016-09-21 21:00 UTC' Reason for outage: Scheduled updates and reboots before F25 beta freeze Let me know if you have any questions/concerns, Tim

2 2

2016-09-12 @ 14:00 UTC - Fedora QA Devel Meeting
by Tim Flink 12 Sep '16

12 Sep '16

# Fedora QA Devel Meeting # Date: 2016-09-02 # Time: 14:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting-1 on irc.freenode.net It's been a while since we've actually had a qadevel meeting and it'd be good to get synced up and updated on what's been going on https://phab.qadevel.cloud.fedoraproject.org/w/meetings/20160912-fedoraqade… If you have any additional topics, please reply to this thread or add them in the wiki doc. Tim Proposed Agenda =============== Announcements and Information ----------------------------- - Please list announcements or significant information items below so the meeting goes faster Tasking ------- - Does anyone need tasks to do? Potential Other Topics ---------------------- - Docker Testing Status - packaging update - fedorahosted shutdown - taskotron self-tests Open Floor ---------- - TBD

1 1

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

qa-devel September 2016