Skip to content
Snippets Groups Projects
  1. Oct 22, 2021
  2. Oct 21, 2021
  3. Sep 28, 2021
  4. Sep 24, 2021
    • David Robertson's avatar
      Update postgresql testing script (#10906) · ea01d4c2
      David Robertson authored
      
      - Use sytest:bionic. Sytest:latest is two years old (do we want
        CI to push out latest at all?) and comes with Python 3.5, which we
        explictly no longer support. The script now runs under PostgreSQL 10
        as a result.
      - Advertise script in the docs
      - Move pg testing script to scripts-dev directory
      - Write to host as the script's exector, not root
      
      A few changes to make it speedier to re-run the tests:
      
      - Create blank DB in the container, not the script, so we don't have to
        `initdb` each time
      - Use a named volume to persist the tox environment, so we don't have to
        fetch and install a bunch of packages from PyPI each time
      
      Co-authored-by: default avatarreivilibre <olivier@librepush.net>
      ea01d4c2
  5. Sep 08, 2021
  6. Aug 17, 2021
  7. Aug 01, 2021
  8. Jul 21, 2021
  9. Jul 14, 2021
  10. Jul 08, 2021
  11. Jun 17, 2021
  12. Jun 07, 2021
  13. May 24, 2021
  14. May 05, 2021
  15. Apr 14, 2021
    • Andrew Morgan's avatar
      Add a dockerfile for running a set of Synapse worker processes (#9162) · 7e460ec2
      Andrew Morgan authored
      This PR adds a Dockerfile and some supporting files to the `docker/` directory. The Dockerfile's intention is to spin up a container with:
      
      * A Synapse main process.
      * Any desired worker processes, defined by a `SYNAPSE_WORKERS` environment variable supplied at runtime.
      * A redis for worker communication.
      * A nginx for routing traffic.
      * A supervisord to start all worker processes and monitor them if any go down.
      
      Note that **this is not currently intended to be used in production**. If you'd like to use Synapse workers with Docker, instead make use of the official image, with one worker per container. The purpose of this dockerfile is currently to allow testing Synapse in worker mode with the [Complement](https://github.com/matrix-org/complement/) test suite.
      
      `configure_workers_and_start.py` is where most of the magic happens in this PR. It reads from environment variables (documented in the file) and creates all necessary config files for the processes. It is the entrypoint of the Dockerfile, and thus is run any time the docker container is spun up, recreating all config files in case you want to use a different set of workers. One can specify which workers they'd like to use by setting the `SYNAPSE_WORKERS` environment variable (as a comma-separated list of arbitrary worker names) or by setting it to `*` for all worker processes. We will be using the latter in CI.
      
      Huge thanks to @MatMaul for helping get this all working :tada: This PR is paired with its equivalent on the Complement side: https://github.com/matrix-org/complement/pull/62.
      
      Note, for the purpose of testing this PR before it's merged: You'll need to (re)build the base Synapse docker image for everything to work (`matrixdotorg/synapse:latest`). Then build the worker-based docker image on top (`matrixdotorg/synapse:workers`). 
      7e460ec2
    • Andrew Morgan's avatar
      Add note to docker docs explaining platform support (#9801) · f16c6cf5
      Andrew Morgan authored
      Context is in https://github.com/matrix-org/synapse/issues/9764#issuecomment-818615894.
      
      I struggled to find a more official link for this. The problem occurs when using WSL1 instead of WSL2, which some Windows platforms (at least Server 2019) still don't have. Docker have updated their documentation to paint a much happier picture now given WSL2's support.
      
      The last sentence here can probably be removed once WSL1 is no longer around... though that will likely not be for a very long time.
      f16c6cf5
  16. Apr 08, 2021
  17. Mar 30, 2021
  18. Mar 26, 2021
  19. Mar 25, 2021
  20. Mar 22, 2021
  21. Mar 16, 2021
  22. Feb 22, 2021
  23. Feb 15, 2021
  24. Jan 29, 2021
  25. Jan 19, 2021
  26. Jan 12, 2021
    • Dan Callahan's avatar
      Fix failures in Debian packaging (#9079) · fa6deb29
      Dan Callahan authored
      Debian package builds were failing for two reasons:
      
       1. Python versions prior to 3.7 throw exceptions when attempting to print
          Unicode characters under a "C" locale. (#9076)
      
       2. We depended on `dh-systemd` which no longer exists in Debian Bullseye, but
          is necessary in Ubuntu Xenial. (#9073)
      
      Setting `LANG="C.UTF-8"` in the build environment fixes the first issue.
      See also: https://bugs.python.org/issue19846
      
      
      
      The second issue is a bit trickier. The dh-systemd package was merged into
      debhelper version 9.20160709 and a transitional package left in its wake.
      
      The transitional dh-systemd package was removed in Debian Bullseye.
      
      However, Ubuntu Xenial ships an older debhelper, and still needs dh-systemd.
      
      Thus, builds were failing on Bullseye since we depended on a package which had
      ceased existing, but we couldn't remove it from the debian/control file and our
      build scripts because we still needed it for Ubuntu Xenial.
      
      We can fix the debian/control issue by listing dh-systemd as an alternative to
      the newer versions of debhelper. Since dh-systemd declares that it depends on
      debhelper, Ubuntu Xenial will select its older dh-systemd which will in turn
      pull in its older debhelper, resulting in no change from the status quo. All
      other supported releases will satisfy the debhelper dependency constraint and
      skip the dh-systemd alternative.
      
      Build scripts were fixed by unconditionally attempting to install dh-systemd on
      all releases and suppressing failures.
      
      Once we drop support for Ubuntu Xenial, we can revert most of this commit and
      rely on the version constraint on debhelper in debian/control.
      
      Fixes #9076
      Fixes #9073
      
      Signed-off-by: default avatarDan Callahan <danc@element.io>
      fa6deb29
  27. Dec 09, 2020
  28. Dec 04, 2020
    • Jordan Bancino's avatar
      Remove version pin prometheus_client dependency (#8875) · 295c209c
      Jordan Bancino authored
      This removes the version pin of the `prometheus_client` dependency, in direct response to #8831. If merged, this will close #8831 
      
      As far as I can tell, no other changes are needed, but as I'm no synapse expert, I'm relying heavily on CI and maintainer reviews for this. My very primitive test of synapse with prometheus_client v0.9.0 on my home server didn't bring up any issues, so we'll see what happens.
      
      Signed-off-by: Jordan Bancino
      295c209c
  29. Nov 17, 2020
  30. Nov 02, 2020
  31. Oct 11, 2020
  32. Oct 09, 2020
  33. Aug 26, 2020
  34. Aug 24, 2020
  35. Aug 11, 2020
    • Erik Johnston's avatar
      Move setting of Filter into code. · 0304ad0c
      Erik Johnston authored
      We do this to prevent foot guns. The default config uses a MemoryFilter,
      but users are free to change to logging to files directly. If they do
      then they have to ensure to set the `filters: [context]` on the right
      handler, otherwise records get written with the wrong context.
      
      Instead we move the logic to happen when we generate a record, which is
      when we *log* rather than *handle*.
      
      (It's possible to add filters to loggers in the config, however they
      don't apply to descendant loggers and so they have to be manually set on
      *every* logger used in the code base)
      0304ad0c
Loading