[AutoQA] #447: Test if updated package version can be installed over the proposed version
by fedora-badges
#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
10 years, 3 months
Proposal: Stop cc'ing Maniphest Tickets to qa-devel@
by Tim Flink
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
10 years, 3 months
Updating qadevel.cloud.fp.o
by Tim Flink
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
10 years, 3 months
[Maniphest] [Created] T46: bodhi directive module
by tflink (Tim Flink)
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
10 years, 3 months
[Maniphest] [Created] T52: investigate logging mechanisms for taskotron runner
by tflink (Tim Flink)
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
10 years, 3 months
[Maniphest] [Created] T43: package resultsdb and resultsdb_frontend as rpm
by tflink (Tim Flink)
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
10 years, 3 months