* Update matrix-appservice-bridge and use our own alias for matrix-bot-sdk
* Bump node version to support matrix-appservice-bridge
* Bump node version in CI
* Fix comments
* Add changelog entry
* Use multi-stage build in Dockerfile
https://github.com/the-draupnir-project/Draupnir/issues/300.
* Move git describe and build into one stage.
Probably won't be a good idea to download an alpine image just to install git.
* Remove git describe step from CI.
* whoopsie, copy version from the build stage not the deleted stamp.
We have a lot of verbose headers, and i think now is the best opportunity we have to become reuse compliant given that we just did two other similar maintenance changes (prettier, typescirpt5 & eslint9 & typescript-eslint).
* synapse_antispam resuse headers.
* delete old unused tslint.json.
* Add REUSE to pre-commit config.
* reuse info for config directory.
* feat: Add SBOM and Attestation to the Docker release process. Also ensure we only deploy platforms on the qemu action as needed and update versions.
This also limits the permissions used
* fix: Make sure there is an empty line at the end of the file
* Fix the qemu platforms
* Setup Yarn Classic through Corepack
* pre-commit: use corepack and silence warnings, add .eslintignore's
* .github/workflows/mjolnir.yml: use yarn through corepack
* mx-tester.yml: use corepack
* mx-tester.yml & package.json: replace references to npx and call corepack more
At least yarn build didn't break locally for me, so I think it's supported here too
* rm & gitignore .yarnrc
* mx-tester.yml & package.json: return to npx since yarn dlx doesn't exist in classic
Mjolnir can now be run as an application service,
meaning it will host multiple independent mjolnirs that can be requested by users.
If the user is on the same homeserver as the appservice is deployed on,
then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget.
Otherwise they can invite the appservice bot to a room they want to protect.
This will create them a mjolnir, a management room and a policy list.
The appservice shares the same docker image as the bot,
but is started slightly differently by specifying "appservice"
as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`.
We could have used another Dockerfile for the appservice,
extending the existing one but we decided not to because there
would have been lots of fiddling around the entrypoint
and logistics involved around adding a tag for it via github actions.
Not to mention that this would be duplicating the image
just to run it with a different binary.
A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice.
Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation):
* draft widget backend
* add `managementRoomId` to `provisionNewMjolnir`
* remove ratelimits from appservice mjolnirs
* add /join endpoint to api backend
* tighter guard around room type in PolicyList
matrix-bot-sdk imporved the types for this
* enable esModuleInterop
* launch and use postgres in a container whilst using mx-tester
* limited access control
policy list used for access control
* Redesign initialization API of many mjolnir.
It's much harder to forget to initialize the components now that you have to in order to construct them in the first place.
* Ammend config not to clash with existing CI
this means that the appsrvice bot is now called 'mjolnir-bot' by default
which was easier than going through old code base and renaming
* Change entrypoint in Dockerfile so that we can start the appservice.
We could have used another Dockerfile for the appservice,
extending the exising one but we decided not to because there
would have been lots of fiddling around the entrypoint
and logistics involved around adding a tag for it via github actions.
Not to mention that this would be duplicating the image
just to run it with a different binary.
This solution is much simpler, backwards compatible, and conscious about the future.
Co-authored-by: gnuxie <gnuxie@element.io>
