laminard: `pages` count wrong with no finished run for a given job

[jbglaw]

Hi!

I just noticed that the event-stream is wrong with a new job added and the job's first run running:

jbglaw@charon:~/ $ jq .< /tmp/x.json 
{
  "type": "status",
  "title": "toolchain.lug-owl.de",
  "version": "1.2",
  "time": 1677853737,
  "data": {
    "recent": [],
    "averageRuntime": 0,
    "pages": 214748365,
    "sort": {
      "page": 0,
      "field": "number",
      "order": "dsc"
    },
    "running": [
      {
        "number": 1,
        "context": "default",
        "started": 1677843618,
        "result": "running",
        "reason": ""
      }
    ],
    "queued": [],
    "description": ""
  }
}

That's generated by:

        db->stmt("SELECT COUNT(*),AVG(completedAt-startedAt) FROM builds WHERE name = ? AND result IS NOT NULL")
        .bind(scope.job)
        .fetch<uint,uint>([&](uint nRuns, uint averageRuntime){
            j.set("averageRuntime", averageRuntime);
            j.set("pages", (nRuns-1) / runsPerPage + 1);
            j.startObject("sort");   
            j.set("page", scope.page)  
             .set("field", scope.field)
             .set("order", scope.order_desc ? "dsc" : "asc")
             .EndObject();
        });

root@lili:/var/lib/laminar# sqlite3 laminar.sqlite 
SQLite version 3.40.1 2022-12-28 14:03:47
Enter ".help" for usage hints.
sqlite> SELECT COUNT(*),AVG(completedAt-startedAt) FROM builds WHERE name = 'gcc-moxie-unknown-moxiebox' AND result IS NOT NULL;
0|
sqlite> 

[jbglaw]

Should be enough to exchange nRuns (in the pages line) with (nRuns<1?1:nRuns). That way, it doesn't get negative, but stays 0, divided by runsPerPage (still zero), plus one (finally: one page).

[ohwgiles]

I think the correct approach is a little more involved. The number of pages should take into account the number of currently running instances of the job

[jbglaw]

Good point, running/queued jobs must be added as well. While looking at this, any chance to make jobs-per-page configurable or dynamic? When I do bisect runs (usually a "parallel" bisect where I don't queue in one job each time, at the mid-point of a range of commits, but n jobs spread over the range, so I can cut down overall wall time (paying with CPU time.) Like for recent builds here: http://toolchain.lug-owl.de/laminar/jobs/gdb-mipsisa64sb1-elf . Would be nice to be able to squeeze more jobs on one page.