Reports regzbot tracking#1925
Conversation
| "--action=new_issues", | ||
| "--to=kernelci-results@groups.io", | ||
| "--cc=gus@collabora.com", | ||
| "--cc=linux@leemhuis.info, ben.copeland@linaro.org", |
There was a problem hiding this comment.
Please use regressions@leemhuis.info for me instead.
Or maybe even better: regressions@lists.linux.dev – I monitor that closely, so it's just as good as mailing me directly. And that way other can join in easily if they want to.
There was a problem hiding this comment.
Thanks! It already goes out to this list, so I have just removed the CC here.
| {% if builds and builds[0]["last_pass_commit"] -%} | ||
| #regzbot introduced: {{ builds[0]["last_pass_commit"] }}..{{ issue["git_commit_hash"] }} | ||
| {% endif -%} | ||
| #regzbot title: build regression on {{ issue["tree_name"] }}/{{ issue["git_repository_branch"] }} | ||
| #regzbot link: https://d.kernelci.org/i/{{ issue["id"] }} | ||
|
|
There was a problem hiding this comment.
Without an "#regzbot introduced: …" regzbot won't act (at least for now, but changing that would not be easy), because it needs a commit or an range where the regressions started. So I'd the "{% endif -%}" needs to move down three lines afaics.
There was a problem hiding this comment.
Have changed in the second review, I have moved the endif down three lines. It will only trigger when there's an introduced change (the full introduced, title and link) and when there's no last-good commit (the regzbot block is omitted). So it'll only appear when the last-good/test query finds a prior passing. If nothing is found within the window (18 days) there's no range so there won't be a regzbot block.
| AND b.compiler = %(compiler)s | ||
| AND b.status = 'PASS' | ||
| AND c.origin = %(origin)s | ||
| AND b._timestamp >= NOW() - INTERVAL %(interval)s |
There was a problem hiding this comment.
might be safer to just use start_time instead of _timestamp, as it will retrieve all builds compiled in the given interval.
There was a problem hiding this comment.
Good idea, have switched to start_time thanks!
| if last_build: | ||
| incident["last_pass"] = last_build[0]["start_time"] | ||
| incident["last_pass_commit"] = last_build[0]["git_commit_hash"] | ||
| incident["last_pass_id"] = last_build[0]["id"] |
There was a problem hiding this comment.
could we call it last_pass_build_id? just to be clear on which id we are talking here.
| platform=platform, | ||
| test_start_time=test["start_time"], | ||
| config_name=test["config_name"], | ||
| field_timestamp=test["_timestamp"], |
There was a problem hiding this comment.
this call is missing a required parameter group_size that limits how far in history we go. We might need to either make this an optional parameter (allowing to return full history) or pass a value large enough here.
There was a problem hiding this comment.
Added group_size=10. Does that fit? A fail streak longer than that will probably lead to no range, which I feel is a safe outcome here. Can bump more though if you like.
base.txt opened with a blank line and an empty header block, so every report rendered with several blank lines before the first content line. Trim the top of base.txt so reports start at their first line, and refresh the metrics example fixture to match. Signed-off-by: Ben Copeland <ben.copeland@linaro.org>
Move the Reported-by and #kernelci trailer up under the summary, and add a regzbot tracking block (introduced/title/link) in its own blank-line-delimited paragraph as the handling-regressions docs require. The block is emitted only when a last known good commit is available, so regzbot is never handed a single unbisected commit or a bare title/link it cannot act on. Signed-off-by: Ben Copeland <ben.copeland@linaro.org>
Add kcidb_last_build_without_issue() to fetch the most recent passing build of the same config (filtered by start_time) that does not carry the issue, and set last_pass_commit on build incidents. For standalone test reports, derive the last passing commit from the status history (passing the required group_size). This lets the mails emit a real last_good..HEAD introduced range. Signed-off-by: Ben Copeland <ben.copeland@linaro.org>
The regressions list is already added in code for mainline/next, so the explicit Cc is not needed. Signed-off-by: Ben Copeland <ben.copeland@linaro.org>
2835e76 to
322375b
Compare
We need to sanity-check the SQL command that returns a sensible "last good build".
Other than that fixes are pretty simple: