| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Make it possible 3 more admin handlers that look useful for future and safe.
Now that we don't deploy the app from local machines, it's problematic
to call them without this wiring.
Remove one old handler that we don't need anymore.
|
| |
|
|
| |
They are shorter, more readable, and don't require temp vars.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use a common number of attempts (10) everywhere in dashboard/app
for db.RunInTransaction() with the custom wrapper runInTransaction().
This should fix the issues when the ErrConcurrentTransaction occurs
after a default number of attempts (3). If the max. limit (10) is not
enough, then it should hint on problem at the tx transaction function itself
for the further debugging.
For very valuable transactions in createBugForCrash(), reportCrash(),
let's leave 30 attempts as it is currently.
Fixes: https://github.com/google/syzkaller/issues/5441
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
If there's no config record for the manager, activeManager would return
a nil pointer to ConfigManager. Assume the priority to be 0 in this
case.
Update the admin.go function that recalculates priorities.
|
| |
|
|
|
|
|
| |
If we just deploy the previous commits, we can end up regenerating many
more bug origin results than necessary. The problem is that we
periodically (every repro retest) regenerate report priorities, and some
of them might temporarily face priority boost due to the new formulae.
|
| |
|
|
|
|
|
| |
In some cases restarting the failed bisection does not make sense,
because we know that the result will be the same.
Let admins choose between invalidating the job and restarting it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Changes to our rootfs, compilers or bisection logic regularly cause
regressions in our bisection accuracy. Retrying them currently entails
fiddling with the GCP datastore directly or mass deleting all failed
bisections.
This change will allow us to retry specific bisections with a single
click.
|
| |
|
|
|
|
| |
Use the JobDoneFlags from dashapi.
Move the default string representation generation to JobDoneFlags.
|
| |
|
|
|
| |
There have been a few issues with HeadReproLevel consistency. Add a
maintenance method that can be used to correct error in the database.
|
| |
|
|
|
| |
This method enables an admin to send an arbitrary message on behalf of
the bot.
|
| |
|
|
|
|
| |
We'll need to invoke this to kick off periodic bug subsystem
recalculation. Otherwise there's no chance to sort bugs by the last
update.
|
| |
|
|
|
|
| |
Sometimes bisections massively fail due to a problem in the bug
bisection code / config. Add a code to reset all failed bisections in
the specified namespace.
|
| |
|
|
|
|
|
|
| |
Until #3161 is implemented, we still need to manually update the DB each
time we create/delete Reporting objects.
The existing code can only append missing items. Make it also support
deleting and inserting them at arbitrary locations.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
updateBugTitles adds missing MergedTitles/AltTitles to bugs.
This can be used to migrate datastore to the new scheme introduced:
by commit fd1036219797 ("dashboard/app: merge duplicate crashes").
Update #1575
|
| |
|
|
|
|
|
|
| |
1. Split cause/fix bisections in the bug table.
2. Show if bisection is inconclusive/unreliable in the bug table.
3. Show if bisection is unreliable on the bug page.
Update #2098
|
| |
|
|
|
| |
Refactor updateBugReportingBatch to be more generic.
Useful helper for other bulk bug updates.
|
| |
|
|
|
|
|
|
|
| |
The old go 1.9 App Engine runtime is now deprecated. Update to the go 1.11
runtime, which still allows us to use the old App Engine library (removed
in the 1.12 runtime).
Closes: #1461 ("dashboard: port app to go111/go112 runtime")
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
|
| |
|
|
|
| |
datastore is too long name for such widely used packages.
Import it as db throughout. Nicely reduces line lengths.
|
| |
|
|
|
|
|
|
| |
updateBugReporting adds missing reporting stages to bugs in a single namespace.
Use with care. There is no undo.
This can be used to migrate datastore to a new config with more reporting stages.
This functionality is intentionally not connected to any handler.
Before invoking it is recommented to stop all connected instances just in case.
|
| |
|
|
|
|
| |
To store bisection logs.
Update #501
|
| |
|
|
|
| |
As per discussion at:
https://groups.google.com/d/msg/syzkaller/zYlQ-b-QPHQ/AJzpeObcBAAJ
|
| |
|
|
| |
Fix typos, non-canonical code, remove dead code, etc.
|
|
|
dropNamespace drops all entities related to a single namespace.
Use with care. There is no undo.
This functionality is intentionally not connected to any handler.
To use it, first make a backup of the datastore. Then, specify the target
namespace in the ns variable, connect the function to a handler, invoke it
and double check the output. Finally, set dryRun to false and invoke again.
|
