| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
As it is problematic to set up automatic bidirectional sharing of
reproducer files between namespaces, let's support the ability to
manually request a reproduction attempt on a specific syz-manager
instance. That should help in the time being.
|
| | |
|
| | |
|
| |
|
|
| |
Display last 500 successful builds for every manager.
|
| |
|
|
|
| |
To ensure service stability, let's rate limit incoming requests to our
web endpoints.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to have a single global `config` variable and access it
throughout the whole dashboard application.
However, this approach has been more and more complicated test writing
-- sometimes we want the config to be only slightly different, so that
it's not worth it adding new namespaces, sometimes we have to test how
dashboard handles config changes over time.
This has already led to a number of hacky contextWithXXX methods that
mocked various parts of the global variable. The rest of the code had to
sometimes still use `config` directly and sometimes invoke getXXX(c)
methods. This is very inconsistent and prone to errors.
With more and more situations where we need to patch the config
appearing (see #4118), let's refactor the application to always access
config via the getConfig(c) method. This allows us to uniformly patch
the config and be sure that the non-patched copy is not accessible from
anywhere else.
|
| |
|
|
|
|
|
|
| |
There are cases when subsystem names change over time.
As we share /namespace/s/name links in our reminder emails, we have to
make sure they remain valid.
Introduce an old => new name map into the dashboard configuration.
|
| |
|
|
|
| |
Currently we only show running/pending/recent jobs. Let admins also see
the list of the latest cause/fix bisections.
|
| |
|
|
|
|
| |
For each label, allow only one value to be specified.
At the same time, allow multiple different labels (subsystem, origin,
prio, etc) be specified together.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let bug labels come in three flavours:
1) Bug labels with multiple values (e.g. `subsystems`).
2) Bug labels with only one value (e.g. `prio`).
3) Flags.
Let users configure bug labels via email by issuing the following
commands:
#syz set subsystems: abc, def
#syz set no-reminders
#syz unset no-reminders
Also let users set tags for invididual bugs in reported bug lists:
#syz set <1> some-tag
|
| |
|
|
|
| |
Count the number of bugs without any subsystem and let users filter bugs
by this criteria.
|
| |
|
|
| |
Add a link to show everything.
|
| |
|
|
|
| |
Display the list of open bugs, subsystem info and stats there.
Make the URL look nice, e.g. /upstream/s/fs
|
| |
|
|
| |
Take the counts from the cache, include links to the filtered bug views.
|
| |
|
|
|
|
| |
After each saved crash, invoke the new pkg/subsystem machinery to infer
the subsystem list. Use 5 crashes with biggest priority to base the
inference on.
|
| |
|
|
|
|
|
| |
Currently it's non obvious whether and what filters are applied to a bug
list.
Display the list to the user and enable them to drop individual filters.
|
| |
|
|
|
| |
In order to do that, we need to tweak the subsystem extraction code. Use
context values, as this should simplify the flow.
|
|
|
The manager= filter limits the dashboard output only to the bugs that
happened on the specified manager (but not exclusively there).
Introduce the only_manager= filter to only show the bugs that happened
ONLY on the specified manager.
|
