* Move src to apps/draupnir/src
https://github.com/the-draupnir-project/planning/issues/100
* Move package.json
https://github.com/the-draupnir-project/planning/issues/100
* Add matrix-basic-types to monorepo.
Get everything working including linting and prettier :3
https://github.com/the-draupnir-project/planning/issues/100
* Add interface-manager to monorepo.
This was a bitch because apparently we forgot to delete node_modules
before creating the workspace package.json. So it had linked a bunch
of local stuff like was in node_modules for Draupnir...
Anyways i think we're still on track.
https://github.com/the-draupnir-project/planning/issues/100
* idk why there are prettier changes in apps but there are.
* Add matrix-protection-suite to monorepo.
https://github.com/the-draupnir-project/planning/issues/100
* Add matrix-protection-suite-for-matrix-bot-sdk
https://github.com/the-draupnir-project/planning/issues/100
We will need to add the real upstreams and versions and remove the
file links as we publish the packages.
* Move mps-interface-adaptor into monorepo
https://github.com/the-draupnir-project/planning/issues/100
Wohoo, i think only draupnir is left now?
* Move Draupnir test files to draupnir directory smh smh smh.
https://github.com/the-draupnir-project/planning/issues/100
* Fix typescript config for tests and eslint.
Now we get proper linting and type checking of tests.
https://github.com/the-draupnir-project/planning/issues/100
* WIP Integrating draupnir into monorepo tooling...
https://github.com/the-draupnir-project/planning/issues/100
We need to stop aliasing bot-sdk but we should first check that
upstream is using a consistent name too.
* Remove matrix-bot-sdk alias for vector fork.
https://github.com/the-draupnir-project/planning/issues/100
* Add top command description type and weave through API.
A more recent version of typescript meant that the exectutor's
contravariance got checked which destroyed the API so we had to make a
top type for command descriptions and parametrise some of the API.
https://github.com/the-draupnir-project/planning/issues/100
* Fix typescript errors related to class property initialisation changes.
https://www.typescriptlang.org/tsconfig/#useDefineForClassFields
Seems like they were using defineProperty before which meant
properites were initialised after the constructor ran.
Honestly i like that more but we're going to stick with what they
intend to be the default.
https://github.com/the-draupnir-project/planning/issues/100
* Fix tests lacking fixtures context.
https://github.com/the-draupnir-project/planning/issues/100
* Fix typescript errors related to error destructuring in tests.
https://github.com/the-draupnir-project/planning/issues/100
* Pin postgres package to workaround upstream issue
https://github.com/porsager/postgres/issues/1150
Documented in DEPENDENCIES.md
https://github.com/the-draupnir-project/planning/issues/100
* Fix contravariance issue in hash store helper.
Part of the TS 5.9 upgrade fallout.
https://github.com/the-draupnir-project/planning/issues/100
* Fix minor typescript 5.9 migration issuess
All typescript errors finished, yay.
* Fix REUSE missing headers.
* Fix assets script in draupnir app.
* Add Draupnir to eslint scope
* Remove the appservice web API.
There are too many eslint errors here to do with unsafe parsing of
properties from the body etc. And there's actually no consumers to
this API. It's also a widget API, and all it does is provision the bot
and nothing more.
* Fix eslint config for DeadDocumentJSX.
It wasn't working well with the jsx templates.
We should probably delete the tsconfig.eslint.json shite now.
* Update src/utils.ts for eslint.
This shit is legacy i hate it.
* Fix eslint errors in config.
Really this is paint over rot since the config doesn't have a schema,
and we can't really make one either.
* Fix eslint issues in ReportManager.
This code is diabolical. It hasn't really been fixed that will take
refactoring and making sure people don't write this sorts of bad code
ever again. Which thankfully we have process in place for.
* Fix clientHelper eslint issues.
* Fix eslint for ImportCommand.
* Grinding eslint fml.
* Fix miscellaneous eslint issues.
* allow no-deprecate for logMessage.
shit's being annoying.
* Fix remaining eslint issues...
We also deleted one of the scripts used to evaluate the performance of
various endpoints, which we were not using.
* Give bot toggle asyncDispose for code consistency.
* Fix package.json access issues.
* Adjust Docker and CI for new app location in monorepo.
* Fix broken integration tests.
* Remove prepare script from matrix-protection-suite package.
Isn't needed anymore
* Fix build:all script missing base files.
* Remove test script from matrix-protection-suite-for-matrix-bot-sdk
It doesn't have any tests :/
* Order of setup is wrong in integration test workflows.
* Fix mps interface adaptor doesn't have any tests.
* Fix appservice registration for test harness.
* Fix matrix-basic-types jest configuration
* Fix no build step in mjolnir.yaml
* Transfer common dev dependencies to the workspace root.
They were just wrong.
Explicitly set the `temp_store` pragma to `file` instead of `memory`
after deciding to place temporary files in `/data` to keep RAM usage
down while addressing #746.
Added a helper function to automatically "flatten" transactions
when you don't need SAVEPOINTs to avoid unnecessary temporary files.
Signed-off-by: Bea <20361868+enbea@users.noreply.github.com>
* 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.
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>
