qa-devel January 2014

qa-devel@lists.fedoraproject.org

12 participants
82 discussions

Re: [AutoQA] #274: systemd unit files test
by fedora-badges 20 Jan '14

20 Jan '14

#274: systemd unit files test --------------------+-------------------------------- Reporter: kparal | Owner: Type: task | Status: closed Priority: major | Milestone: Future test cases Component: tests | Resolution: wontfix Keywords: | Blocked By: Blocking: | --------------------+-------------------------------- Changes (by adamwill): * resolution: => wontfix * status: new => closed Comment: Migrated to Phabricator: https://phab.qadevel.cloud.fedoraproject.org/T59 -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/274#comment:1> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 0

Re: [AutoQA] #197: New test: "See also" validity in man pages
by fedora-badges 20 Jan '14

20 Jan '14

#197: New test: "See also" validity in man pages --------------------+-------------------------------- Reporter: kparal | Owner: Type: task | Status: closed Priority: major | Milestone: Future test cases Component: tests | Resolution: wontfix Keywords: | Blocked By: Blocking: | --------------------+-------------------------------- Changes (by adamwill): * status: new => closed * resolution: => wontfix Comment: Migrated to Phabricator: https://phab.qadevel.cloud.fedoraproject.org/T58 -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/197#comment:1> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 0

[AutoQA] #447: Test if updated package version can be installed over the proposed version
by fedora-badges 20 Jan '14

20 Jan '14

#447: Test if updated package version can be installed over the proposed version ---------------------+-------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: minor | Milestone: Future tasks Component: tests | Keywords: Blocked By: | Blocking: ---------------------+-------------------------- ---- We know that some updates we push will be buggy; hopefully not this buggy, but significantly buggy nevertheless. So, we know that a 2nd update of the package to fix the 1st update will from time to time be required. If only we could have an automated test that: Takes the SRPM of a proposed update[[BR]] Adds one new file, and one new scriptlet (line?), bumps %version, and builds this.[[BR]] Tests that update from "original" to "proposed update" and then to "proposed update + 1" works as expected. ---- https://fedorahosted.org/fesco/ticket/1223#comment:5 -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/447> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

Re: [AutoQA] #229: Create per-update file conflicts test
by fedora-badges 20 Jan '14

20 Jan '14

#229: Create per-update file conflicts test -------------------------+-------------------------------- Reporter: jlaska | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Future test cases Component: tests | Resolution: wontfix Keywords: | Blocked By: Blocking: | -------------------------+-------------------------------- Changes (by adamwill): * resolution: => wontfix * status: new => closed Comment: Migrated to Phabricator: https://phab.qadevel.cloud.fedoraproject.org/T57 -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/229#comment:1> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 0

Proposal: Stop cc'ing Maniphest Tickets to qa-devel@
by Tim Flink 20 Jan '14

20 Jan '14

Over the last couple of days, a lot of tickets have been created and all of those tickets have sent messages here. While I see some benefit to having all these tickets emailed out to the list, I'm also a bit worried that they can start drowning out other non-ticket conversations on the list. I'm honestly not sure I see a whole lot of benefit to continuing this since any user can create rules to have themselves cc'd to tickets based on that ticket's project, priority etc. (see the herald application when you're logged into phabricator). Any thoughts on whether it would be OK to start asking folks to create herald rules if they want to see all the tickets or if there is enough value in continuing our policy of cc'ing the list on all tickets? Tim

6 8

Initial Contribution Guide for Taskotron (rough draft)
by Tim Flink 20 Jan '14

20 Jan '14

This is a very rough draft but should hopefully answer a few questions about where to find code, what tools to use etc. https://fedoraproject.org/wiki/User:Tflink/taskotron_contribution_guide That link will change once we get the documentation situation figured out, but it works for now. If you have any questions, please ask Tim

1 0

Updating qadevel.cloud.fp.o
by Tim Flink 20 Jan '14

20 Jan '14

I'm about to do some updates on qadevel (including phabricator) and it will be down for a little bit as I make a few changes. I'll send out an email when the changes are complete. Tim

1 1

[Maniphest] [Created] T46: bodhi directive module
by tflink (Tim Flink) 16 Jan '14

16 Jan '14

tflink created this task. tflink added subscribers: qa-devel, tflink. tflink added a project: taskotron TASK DESCRIPTION For phase 1, we need to replace AutoQA. This means that we need the ability to report results directly to bodhi - at least for the short term. The directive will take in TAP output and submit comments to bodhi using FAS credentials stored in a configuration file or injected by the runner (as in the examples). If the implementation uses injection, **make sure** that the actual credentials are not logged anywhere public. report: bodhi: baseurl={{bodhiurl}} username={{fasuser}} password={{faspassword}} doreport=all The main corner case of note is depcheck. The current paradigm is that depcheck will add reporting comments on state change (PASS to FAIL or FAIL to PASS) or repeat comments if the update in question has been in FAIL for a configurable number of days. Example directive for depcheck: report: bodhi: baseurl={{bodhiurl}} username={{fasuser}} password={{faspassword}} doreport=onchange The code for this should be mostly complete in AutoQA (both in lib and depcheck) and hopefully will require little modification. TASK DETAIL https://phab.qadevel.cloud.fedoraproject.org/T46 To: tflink Cc: qa-devel, tflink

1 4

[Maniphest] [Created] T52: investigate logging mechanisms for taskotron runner
by tflink (Tim Flink) 16 Jan '14

16 Jan '14

tflink created this task. tflink added subscribers: qa-devel, tflink. tflink added a project: taskotron TASK DESCRIPTION At the moment, all output from the runner is done with python 'print' statements. This is not the best way to be doing things but before implementing anything better, some investigation needs to be done. [[http://pythonhosted.org/Logbook/index.html|Logbook]] looks to be an interesting project that could suit our needs well. I don't think we need any of the enhancements it brings over the stdlib logging module yet but I'm interested in the idea of sending errors off to a central location. As the implementation of taskotron grows, I think that would help us keep on top of client failures. Investigate logbook and determine: - is logbook mature enough to use in production - would the logging enhancements be useful enough to us to justify using a less-standard logging mechanism - how much extra effort would it take to use logbook instead of logging TASK DETAIL https://phab.qadevel.cloud.fedoraproject.org/T52 To: tflink Cc: qa-devel, tflink

1 2

[Maniphest] [Created] T43: package resultsdb and resultsdb_frontend as rpm
by tflink (Tim Flink) 16 Jan '14

16 Jan '14

tflink created this task. tflink added subscribers: qa-devel, tflink. tflink added a project: resultsdb TASK DESCRIPTION Before we deploy anything beyond a dev environment, these deployments need to be automated and repeatable. The best way to make this happen for us is to package everything appropriate as RPM. Package resultsdb and resultsdb_frontend as RPM so that they can be hosted in a repository. This doesn't mean that getting the packages into fedora is required at this point, just working spec files in git. TASK DETAIL https://phab.qadevel.cloud.fedoraproject.org/T43 To: tflink Cc: qa-devel, tflink

1 2

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

qa-devel January 2014