See the issue for the problem description.
Include repro level into reporting priority,
so that we can order by just it during selection
and ignore ReproC/ReproSyz.
Fixes#634
dashboard/app/api.go:390:28⚠️ do not pass a nil Context, even if a function permits it; pass context.TODO if you are unsure about which Context to use (SA1012) (megacheck)
Currently one needs to switch between config_stub.go and prod
config back and forth on every deployment. This is very
inconvinient. Rework config, so that switching is not necessary.
bug.LastTime is updated on every crash, even if we don't save it.
As the result we did not save recent crashes for popular bugs at all.
Fix this by introducing bug.LastSavedCrash.
This implements 2 features:
1. It's now possible to specify exact commit when testing as:
2. It's possible to test without patch attached
assuming the patch is already committed to the tested tree.
Fixes#558
When purging crashes we currently sort by priority (manager) first,
as the result if we have enough month-old crashes on upstream,
we stop saving any new crashes on other branches.
Sort by time first, but keep at least 1 crash per manager.
Currently dashboard sends patch testing result to full bug CC list
(which includes kernel mailing lists). This is unnecessary and causes
problems with patchwork.
Reply only to people in the testing request CC list
(adding our mailing list if it was missing).
Fixes#526
This is the bulk of work for opening dashboard.
Implement finer-grained access control (admin/user/public).
Show only info designated to the current user access level.
Rework UIs for more clarity re bug statuses.
Show fixed bug.
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.
Only reset manager failed build if it uploaded _new_
successful build. On manager restart it uploads its
_old_ working build, and it should not reset a later
failed build.
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.
We frequently get "too much contention" errors when saving crashes.
Reduce contention by:
- finding/creating bug before the transaction
- saving crash outside of transaction
- not saving crashes when we have too many of them already
- 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
We see some episodic
"failed to delete old crash texts: Call error 11: Deadline exceeded (timeout)"
errors in logs.
Deleting at most 10 bugs should be enough since we do this check
after adding each new crash.
The new app is based on our experience with syz-dash
and is meant to supersede it. This app aims at full
automation of bug lifecycle: reporting, tracking updates,
closing fixed bugs.
The main differences are:
- this app has support for reporting bugs
either by email or using an arbitrary external reporting system
- this app tracks status of bugs
- this app captures more info about kernel builds
