tflink created this task.
tflink added a subscriber: tflink.
tflink added a project: blockerbugs
TASK DESCRIPTION
I got a report of a failed proposal today where the form said there were errors but everything looks fine and no details were provided.
There is currently no logging of form errors in the app, and that would have been useful in this case. If there's one report, I suspect that there have been other form validation failures which have gone unreported. Attached to this bug is screenshot of what the user reported
{F10}
TASK DETAIL
https://phab.qadevel.cloud.fedoraproject.org/T24
To: tflink
Cc: qa-devel, tflink
I've been working on this for a bit but finally have enough together
that we can start talking about the task description format for
taskotron.
The code to actually run tasks (well, task. for now, rpmlint is all
that's supported) is up at:
https://bitbucket.org/fedoraqa/libtaskotron-demo
The runner code isn't very good yet but I didn't want to wait until it
was done before starting to discuss the task description format.
Continuing the use of rpmlint as an example, I have a task repository
set up on bitbucket:
https://bitbucket.org/fedoraqa/task-rpmlint
At the moment, that task yaml file for rpmlint [1] looks like:
dependencies:
- rpmlint
- libtaskbot
input:
args: envr,arch
preparation:
koji: download $envr
execution:
python: run_rpmlint.py $workdir
post:
shell: clean $workdir
report:
resultdb: something
[1]https://bitbucket.org/fedoraqa/task-rpmlint/src/be90c723a11f3cec3a7ee72e3…
In a nutshell, the idea is to keep repetitive code out of the tasks
without requiring everything to be written in the same language or
porting the library to any language people want to use (perl, c, bash
etc.).
The execution of the task is described in the yml file and eventually
delegates actual execution to the python file described in that yml
file. Output, for now, is in TAP format. The runner just spits it out
as text for the moment but eventually, that TAP output will be used for
reporting the results.
Items prepended with '$' represent variables - either things determined
at runtime (the working directory) or things that are arguments to the
specific task run (the envr of packages to check).
Examples of what future features could look like:
execution:
beaker: job=somejob.xml distro=$latestfedora
preparation:
bodhi: download $updates
preparation:
openstack: image=imagename config=someconfigtype size=m1.small
execution:
infinity: config=test/sometest.cfg
Any thoughts on whether this direction is a good direction to take or
suggestions on how the format could be improved? Eventually, I want to
send this out to devel@ for input but figured that the smaller group of
folks here would be a good start.
Thanks,
Tim
tflink created this task.
tflink added subscribers: qa-devel, tflink.
tflink added a project: taskotron
TASK DESCRIPTION
In the demo code, the directives (koji, python, etc.) are all loaded at run time. While this works for the time being, it will start contributing to undesired side-effects as we add functionality.
- increased imports @ runtime
- longer requires (instead of optional requires)
- invitation to more tightly coupled code
Change the code around so that directive modules are only loaded if they are used in the task description.
simple example:
preparation:
foo: somearg
execution:
bar: someotherarg
In this case, the only directive modules loaded would be foo and bar. baz could be implemented but it would not be loaded.
TASK DETAIL
https://phab.qadevel.cloud.fedoraproject.org/T45
To: tflink
Cc: qa-devel, tflink
tflink created this task.
tflink added subscribers: qa-devel, tflink.
tflink added a project: taskotron
TASK DESCRIPTION
Tracking ticket for notifications and reporting required for taskotron phase 1
TASK DETAIL
https://phab.qadevel.cloud.fedoraproject.org/T42
To: tflink
Cc: qa-devel, tflink
tflink created this task.
tflink added subscribers: qa-devel, tflink.
tflink added a project: taskotron
TASK DESCRIPTION
For phase 1, we will be relying on [[https://fedmsg.com|fedmsg]] and [[https://github.com/fedora-infra/fmn|fedmsg-notifier]] to do most of the notification legwork.
The data contained in these messages are effectively JSON blobs. We need to figure out:
- what fields we want to have emitted for notifications
- how many message types we want to emit
- when messages should be emitted
TASK DETAIL
https://phab.qadevel.cloud.fedoraproject.org/T44
To: tflink
Cc: qa-devel, tflink
mkrizek created this task.
mkrizek claimed this task.
mkrizek added a subscriber: mkrizek.
mkrizek added a project: blockerbugs
TASK DESCRIPTION
Currently, the app knows of no way how to deal with updates that were deleted from bodhi. This results in displaying deleted update as a potential fix for a bug. Also, the app display an obsolete update as a potential fix which it shouldn't.
The update sync code should go through the updates stored in the app's db and somehow mark those that were no longer present in bodhi or that have status 'obsolete' as 'do not display'.
TASK DETAIL
https://phab.qadevel.cloud.fedoraproject.org/T21
To: mkrizek
Cc: qa-devel, mkrizek
mkrizek created this task.
mkrizek added a subscriber: mkrizek.
mkrizek added a project: blockerbugs
TASK DESCRIPTION
Moved from trac [[ https://fedorahosted.org/fedora-qa/ticket/318 | https://fedorahosted.org/fedora-qa/ticket/318 ]]:
"When bug A (proposed/accepted blocker) is closed as a duplicate of bug B (not proposed as a blocker), it disappears from the list. Unfortunately a lot of developers won't transfer the Blocks: and Whiteboard: fields, so we might lose track of some important bugs this way.
Displaying A or B in the list even when this happens would be nice. Displaying B is probably the preferable way. There could be a special icon indicating that B is displayed because of recursive dependencies and tooltip would specify it is because of bug A."
TASK DETAIL
https://phab.qadevel.cloud.fedoraproject.org/T32
To: mkrizek
Cc: qa-devel, mkrizek