The anonymous user has ID `None`. Previously, this exception was raised:
NoReverseMatch: Reverse for 'user-profile' with arguments '(None,)' not found. 1 pattern(s) tried: ['user/(?P<pk>\\d+)/profile/$']
One of the effects is that you don't get this Django error e-mail any more:
> ```
> [Django] ERROR: "GET /favicon.ico HTTP/1.0" 500 106
> ```
`.ico` was auto-created as following:
```
$ ( cd cabot/static/arachnys/img && convert icon_*x*.png favicon.ico && file favicon.ico )
favicon.ico: MS Windows icon resource - 2 icons, 48x48, 32 bits/pixel, 96x96, 32 bits/pixel
```
Debounce is “the number of successive failures
permitted before check will be marked as failed”.
It is very useful to avoid alerts on expected hiccups.
For checks whose retry logic lies in Cabot using `frequency`
(which is the case for Graphite, HTTP, and ICMP checks),
it makes sense that the debounce is about how often Cabot retried things.
For JenkinsChecks, however, we have no control over
how often Cabot checks the job. This means that even a
debounce of eg 5 can trigger an alert over 1 job failure.
A simpler implementation of this was to loop over the
recent results, count how many distinct jobs have failed,
(using the job number stored in the `status_check_result`),
and set the status to fail if this is higher than the debounce.
However, Cabot only considers the last 10 results (hardcoded value).
Since Cabot checks the job at fairly high frequency (or at least a
frequency higher than the Jenkins run frequency), this can mean
the status would switch to pass after 10 checks of a single check failure.
We thus need to enrich the StatusCheckResult data model
to store that information.
- Add field `consecutive_failures` to StatusCheckResult model
(and associated migration).
- Retrieve from Jenkins the last good build, and compute from
that the number of consecutive failures
- Also display the consecutive failures in the Check results page
Closes#537
A new endpoint to return the currently on call users
Also added a serialize method to plugins to allow plugin data (e.g.
slack alias) to get returned with the method.
This is needed when running behind a reverse proxy,
otherwise we get redirected to plain HTTP which does
not match the expected URL in the provider.
Per the python-social-auth documentation:
```
On projects behind a reverse proxy that uses HTTPS, the redirect
URIs can have the wrong schema (http:// instead of https://) if
the request lacks the appropriate headers, which might cause
errors during the auth process.
To force HTTPS in the final URIs set this setting to True
```
https://python-social-auth-docs.readthedocs.io/en/latest/configuration/settings.html
