docs

examples

group_vars

inventory

roles

matrix-base

matrix-bridge-appservice-discord

matrix-bridge-appservice-irc

matrix-bridge-appservice-slack

matrix-bridge-appservice-webhooks

matrix-bridge-mautrix-facebook

matrix-bridge-mautrix-hangouts

matrix-bridge-mautrix-telegram

matrix-bridge-mautrix-whatsapp

matrix-common-after

matrix-corporal

matrix-coturn

matrix-dimension

matrix-email2matrix

matrix-mailer

matrix-mxisd

matrix-nginx-proxy

defaults

tasks

templates

vars

main.yml

matrix-postgres

matrix-riot-web

matrix-synapse

.editorconfig

.gitignore

CHANGELOG.md

LICENSE

README.md

ansible.cfg

setup.yml

Slavi Pantaleev f4f06ae068 Make matrix-nginx-proxy role independent of others ...

The matrix-nginx-proxy role can now be used independently.
This makes it consistent with all other roles, with
the `matrix-base` role remaining as their only dependency.

Separating matrix-nginx-proxy was relatively straightforward, with
the exception of the Mautrix Telegram reverse-proxying configuration.
Mautrix Telegram, being an extension/bridge, does not feel important enough
to justify its own special handling in matrix-nginx-proxy.

Thus, we've introduced the concept of "additional configuration blocks"
(`matrix_nginx_proxy_proxy_matrix_additional_server_configuration_blocks`),
where any module can register its own custom nginx server blocks.

For such dynamic registration to work, the order of role execution
becomes important. To make it possible for each module participating
in dynamic registration to verify that the order of execution is
correct, we've also introduced a `matrix_nginx_proxy_role_executed`
variable.

It should be noted that this doesn't make the matrix-synapse role
dependent on matrix-nginx-proxy. It's optional runtime detection
and registration, and it only happens in the matrix-synapse role
when `matrix_mautrix_telegram_enabled: true`.

2019-01-17 13:32:46 +02:00

..

main.yml

Make matrix-nginx-proxy role independent of others

2019-01-17 13:32:46 +02:00