The drone-server can't reach the agent if its `--server` flag is set to
the drone-server's address.

Drone 0.8.1+ requires at least Docker API version > 1.26

The `chdir` command was not executed reliably so I use the absolute path
to gitea's config file instead.

This was one of the reason I received "registration is disabled" error
when trying to start Drone CI.

This fixes some authentication issues with Drone CI.

The `chdir` command was not executed reliably so I use the absolute path
to gitea's config file instead.

This adds signed commit support and provides a new UI.

Previously, the git status was set after all roles were applied, i.e.
the value was still "unknown"

The header was removed in the latest release anyways.

See https://golang.org/pkg/time/#ParseDuration for valid duration
values.

```sh
$ caddy -conf=/etc/caddy/Caddyfile -validate
2017/10/08 12:43:37 /etc/caddy/Caddyfile:92 - Error during parsing: You are using plugin 'upload' on a site without TLS.
```

TLS is not disabled for this site.
Unfortunately, I can't open an issue for the plugin because it resides
on a self-hosted gitlab instance where account creating is disabled.

If @wmark reads this, please check if you can fix the problem with
`caddy -validate`.

This backup option omits jupyter.

This would take way too long and therefore cause a downtime which can be
prevented by backing those folders up in a separate target that does not
stop caddy.

Pro tip: If you own more than 5 subdomains than keep a backup of your
already issued certificates because you can issue up two 20 a week but
only renew 5!
Let's run the service with staging certificates for a week :|

This simplifies the development because only the root CA has to be
trusted in the browser.

From https://caddyserver.com/docs/http.prometheus

You'll need to put this module early in the chain,
so that the duration histogram actually makes sense. I've put it at number 0.

This is based on this gist: https://gist.github.com/jdeathe/4c08460eb0bac99da32748bcbda39333

Unfortunately, since FF 48 and Chrome 58 it is required to set a
SubjectAltName (SAN) in the certificate because the CommonName (CN)
support was removed.

There is also this https://alexanderzeitler.com/articles/Fixing-Chrome-missing_subjectAltName-selfsigned-cert-openssl/
article which uses a custom root CA. Maybe I give this a try.

Nonetheless, I can't thank letsencrypt enough because actually they made
it easier to get a valid certificate then to generate a self-signed
one.

This is useful because the certificate is static (tls self-signed
generates one on each start) you only have to confirm the security
exception once.

The newlines before the `{% endif %}`s are required because jinja
trims the newlines from the end of a block.