Skip to content
Snippets Groups Projects
  1. Sep 21, 2021
  2. Sep 20, 2021
  3. Aug 23, 2021
  4. Aug 12, 2021
  5. Aug 11, 2021
  6. Aug 10, 2021
  7. Aug 05, 2021
  8. Aug 02, 2021
  9. Jul 27, 2021
  10. Jul 26, 2021
  11. Jul 22, 2021
  12. Jul 21, 2021
  13. Jul 20, 2021
  14. Jul 14, 2021
    • Richard van der Hoff's avatar
      Make GHA config more efficient (#10383) · 07e0992a
      Richard van der Hoff authored
      A few things here:
      
      * Build the debs for single distro for each PR, so that we can see if it breaks. Do the same for develop. Building all the debs ties up the GHA workers for ages.
      * Stop building the debs for release branches. Again, it takes ages, and I don't think anyone is actually going to stop and look at them. We'll know they are working when we make an RC.
      * Change the configs so that if we manually cancel a workflow, it actually does something.
      07e0992a
  15. Jul 13, 2021
  16. Jul 12, 2021
  17. Jul 07, 2021
  18. Jun 24, 2021
  19. Jun 18, 2021
    • Andrew Morgan's avatar
      Deploy a documentation version for each new Synapse release (#10198) · 7c536d0f
      Andrew Morgan authored
      This PR will run a new "Deploy release-specific documentation" job whenever a push to a branch name matching `release-v*` occurs. Doing so will create/add to a folder named `vX.Y` on the `gh-pages` branch. Doing so will allow us to build up `major.minor` releases of the docs as we release Synapse.
      
      This is especially useful for having a mechanism for keeping around documentation of old/removed features (for those running older versions of Synapse), without needing to clutter the latest copy of the docs.
      
      After a [discussion](https://matrix.to/#/!XaqDhxuTIlvldquJaV:matrix.org/$rKmkBmQle8OwTlGcoyu0BkcWXdnHW3_oap8BMgclwIY?via=matrix.org&via=vector.modular.im&via=envs.net) in #synapse-dev, we wanted to use tags to trigger the documentation deployments, which I agreed with. However, I soon realised that the bash-foo required to turn a tag of `v1.2.3rc1` into `1.2` was a lot more complex than the branch's `release-v1.2`. So, I've gone with the latter for simplicity.
      
      In the future we'll have some UI on the website to switch between versions, but for now you can simply just change 'develop' to 'v1.2' in the URL.
      7c536d0f
  20. Jun 11, 2021
    • Patrick Cloke's avatar
      Use the matching complement branch when running tests in CI. (#10160) · a14884fb
      Patrick Cloke authored
      This implements similar behavior to sytest where a matching branch is used,
      if one exists. This is useful when needing to modify both application code
      and tests at the same time. The following rules are used to find a matching
      complement branch:
      
      1. Search for the branch name of the pull request. (E.g. feature/foo.)
      2. Search for the base branch of the pull request. (E.g. develop or release-vX.Y.)
      3. Search for the reference branch of the commit. (E.g. master or release-vX.Y.)
      4. Fallback to 'master', the default complement branch name.
      a14884fb
  21. Jun 09, 2021
  22. Jun 03, 2021
  23. Jun 02, 2021
  24. May 26, 2021
  25. May 10, 2021
  26. Apr 09, 2021
  27. Aug 05, 2020
  28. May 01, 2020
    • Brendan Abolivier's avatar
      Make it clearer that #synapse:matrix.org is our support channel (#7379) · a6b32bad
      Brendan Abolivier authored
      This PR moves the "support is in #synapse:matrix.org" in the bug report template outside of the comment as some people seem to ignore what's in the comments, and phrase it a bit more like the support request template. It also adds a default issue template that says the same thing. It's also adding a notice about the security disclosure to both the default template and the bug report one.
      
      It also adds a badge to the top of the README with an alt text saying about the same message if the badge doesn't load (e.g. if matrix.org is slow).
      
      Fixes #6826 
      a6b32bad
  29. Jan 16, 2020
  30. Dec 04, 2019
Loading