| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
TitleToCrashType is a simple function with no heavy dependencies
that is used by the dashboard app.
Currnetly we have to import pkg/report into dashboard/app,
and this package has lots of heavy deps (symbolizer, demangler,
coverage report generation, etc).
Move TitleToCrashType to pkg/report/crash (where it arguably belongs anyway).
|
| | |
|
| | |
|
| |
|
|
| |
They are shorter, more readable, and don't require temp vars.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
It allows to control known parameters:
1. Period (months or days).
2. Target subsystem.
3. Target manager.
And adds the disabled "Only unique" checkbox.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This change makes amount of coverage columns configurable.
The default width is 4 columns now (months, days, quarters).
Previous default was 12 and was too wide.
|
| |
|
|
|
|
| |
We currently merge bigquery data for every line coverage request.
Let's read cached lines coverage data from spanner instead.
It allows to get only 1 file version from git and skip the data merge step.
|
| |
|
|
|
| |
We don't want to scale the github repo usage.
Let's eventually switch to the internal service.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It directly uses the coverage signals from BigQuery.
There is no need to wait for the coverage_batch cron jobs.
Looks good for debugging.
Limitations:
1. It is slow. I know how to speed up but want to stabilize the UI first.
2. It is expensive because of the direct BQ requests. Limited to admin only because of it.
3. It merges only the commits reachable on github because of the gitweb throttling.
After the UI stabilization I'll save all the required artifacts to spanner and make this page publicly available.
To merge all the commits, not the github reachable only, http git caching instance is needed.
|
| |
|
|
|
|
|
|
|
| |
Current coverage is a week long data merge for every day.
The goal is to show a monthly data by default and
make daily data available for &period=day requests.
This commit makes the first two steps:
1. Make the day a day long, not a week long aggregation.
2. Enable the month long merges available for &period=month.
|
| | |
|
| |
|
|
|
| |
Total coverage page defaults to quarters (?period=quarter).
Monthly data is available with ?period=month.
|
| |
|
|
| |
It also fixes the context propagation bug.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Bugs that are delayed from reaching the final reporting only by embargo
can also be considered found and stable (e.g. not one-off corruptions
staged in moderation).
|
| |
|
|
|
|
|
| |
1. Don't considered invalid bugs in non-last reporting.
E.g. invalidated KCSAN reports that were never reported publicly.
2. Days start with 1, not with 0.
|
| |
|
|
| |
Useful to estimate overall syzbot performance.
|
| |
|
|
|
|
|
|
|
| |
1. Use Fixed date for fixed bugs as X coord.
This avoids the top part of the graph being skewed 45°.
2. Slightlyh randomize Y coord for dots near X axis.
Currently they all are shown at +/-0.1 and blend together.
3. Randomize unfixed bugs a bit more (i%10 instead of i%7).
There are lots of them and they blend together.
|
| | |
|
| | |
|
| |
|
|
|
| |
This statistics allows us to better estimate the amount of coverage that
is lost after every syzbot instance is restarted.
|
| |
|
|
| |
Add a Namespace x Type index and use it to speed up graphs generation.
|
| |
|
|
|
| |
In many cases we want to just access the namespaces's config.
Introduce a special helper function to keep code shorter and more conscise.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
Currently we remove all invalidated and deduplicated bugs, which skews
the graph over time - many of the currently open bugs will be
invalidated, too, and disappear from the graph later.
Let's be more historically correct and display the actual number of open
bugs at every moment in history.
|
| |
|
| |
* dashboard/app/graphs.go: return 400 if bad input
|
| |
|
|
| |
Show graph pages to users who have access to the bugs themselves.
|
| |
|
|
|
| |
Show top crashers for X last days.
Show graph with daily shares of crashes that satisfy user-entered regexps.
|
| |
|
|
|
|
| |
1. Updated the "include"s.
2. No logs read API in the AppEngine anymore. Replaced by the GCP logging API.
3. Use "GO111MODULE=off gcloud beta app deploy ./dashboard/app/app.yaml --no-promote" to test new deployment.
4. Updated the documentation.
|
| |
|
|
|
|
|
|
| |
Show also the "executions per second" graph on the dashboard.
We have differing amouns of fuzzing time each day, so it is very hard
to analyze the dynamics of "exec total" otherwise.
Truncate hints to 2 digits after the floating points.
|
| |
|
