On Wed, 11 Jan 2017 12:43:23 +0100 Lukas Brabec <lbra...@redhat.com> wrote:
> Hi team, > > I would like to open discussion on topic "Task Result Dashboards". > I'm posting here in order to avoid long of the grid discussions we > had last time regarding the docker testing stuff. > There is a tracking ticket in phab [1] that links to tflink's initial > ideas [2]. > > * What is the motivation, what do we want to achieve with such > dashboards and who is the 'non-techincal audience'? The motivation is to enable more complex visualizations of results. If we're interested in the current state of all ruby packages or all python packages it's not all that easy to see that at a glance with our current resultsdb interfaces. I can also see having a dashboard for all critpath packages or all packages needed for building a livecd being a useful thing to render > * Runnable once a day or once per hour at minimum; does this imply > static periodically refreshed page? If so, what is the motivation for > static website? The idea was to start with static site generation because it doesn't require an application server, is easy to host and likely easier to develop, at least initially. > After brief discussion with jskladan, I understand that resultsDB > would be able to handle requests from dynamic page. Sure but then someone would have to write and maintain it. The things that drove me towards static site generation are: - easier to make something quickly - enables easier dashboard contribution; we just need the description of what's being visualized. > * I'm not sure what exactly is meant by 'item tag' in the examples > section. > > * Would the YAML configuration look something like this: > > url: link.to.resultsdbapi.org > overview: > - testplan: > - name: LAMP > - items: > - mariadb > - httpd > - tasks: > - and: > - rpmlint > - depcheck > - or: > - foo > - bar I was thinking more of the example yaml that's in the git repo at taskdash/mockups/yamlspec.yml [1] but I'm not really tied to it strongly - so long as it works and the format is easy enough to understand. > Is there going to be any additional grouping (for example, based > on arch) or some kind of more precise outcome aggregation (only warn > if part of testplan is failing, etc.) Maybe but I think those features can be added later. Are you of the mind that we need to take those things into account now? > * Are we going to generate the dashbord for the latest results only, > or/and some kind of summary over given period in history? For now, the latest results. In my mind, we'd be running the dashboard creation on a cron job or in response to fedmsgs. At that point, we'd date the generated dashboards and keep a record of those without needing a lot more complexity > * How are Task dasboards related to Static dashboards [3] They're the same thing - a demonstration of me somehow forgetting that there was a basic ticket when I wrote T738. Thanks for taking this on, it'll be great to have some nicer status displays of the kinds of checks running in Taskotron. Tim [1] https://bitbucket.org/tflink/taskdash/src/67f370e62f163de94d8404331d13c404fbf1ec73/mockups/yamlspec.yml?at=master&fileviewer=file-view-default > > [1] https://phab.qa.fedoraproject.org/T725 > [2] https://bitbucket.org/tflink/taskdash > [3] https://phab.qa.fedoraproject.org/T738 > _______________________________________________ > qa-devel mailing list -- qa-devel@lists.fedoraproject.org > To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
pgp9U1e5TiN7K.pgp
Description: OpenPGP digital signature
_______________________________________________ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
