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:
> * 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