Collect kernel build commit title/date.
Add support for kernel repo aliases (to be able
to say linux-next instead of full git repo address).
Collect on what managers a bug happened.
Reuse Crash.ReportLen as generic crash reporting priority.
Make it possible to prioritize reporting of particular
kernel repos and arches.
Fixes#473
We currently can silently switch crashes when report
to the next reporting, or test a patch using a repro
from a different crash.
Remember what crash we reported for a bug and use it
in both cases.
Support the new scheme of associating fixing commits with bugs.
Now we provide a tag along the lines of:
Reported-by: <syzbot+a4a91f6fc35e102@syzkaller.appspotmail.com>
The tag is supposed to be added to the commit.
Then we parse commit logs and extract these tags.
The final part on the dashboard is not ready yet,
but syz-ci should already parse and send the tags.
Make it possible to monitor health and operation
of all managers from dashboard.
1. Notify dashboard about internal syz-ci errors
(currently we don't know when/if they happen).
2. Send statistics from managers to dashboard.
Boot and minimally test images before declaring them as good
and switching to using them.
If image build/boot/test fails, upload report about this to dashboard.
Provide better errors from bug update command.
In particular, distinguish between bad updates and internal errors.
Also better messages.
Allow duping onto closed bugs.
Don't allow unduping from closed bugs.
- save Message-ID and use In-Reply-To in subsequent messages
- remember additional CC entries added manually
- don't mail to maintainers if maintainers list is empty
- improve mail formatting and add a footer
- implement upstream/fix/dup/invalid commands over email
- add tests
Detect when we send first/non-first email for a bug.
Detect when we send moderation/non-moderation email for a bug.
Fix setting repro level in email reports.
Add end-to-end email reporting tests.
json decoding behavior is somewhat surprising
(see // https://github.com/golang/go/issues/21092).
This behavior is especially easy to hit in tests
that reuse reply objects.
To avoid any surprises, we zero the reply.
