feat: migration files for the database schema

[gentlementlegen]

Resolves ubiquity/ubiquibot#919

It is done in this repository as the issue was opened in the old Ubiquibot repo which should not be relevant soon. The schema is a copy of the one currently used by wfzpewmlyiozupulbuur Supabase project.

The changes are already applied in the database, these migrations just reflect its current state.

[github-actions]

Unused dependencies (4)

Filename	dependencies
package.json	@octokit/webhooks-types create-cloudflare octokit universal-github-app-jwt

Unused devDependencies (4)

Filename	devDependencies
package.json	@mswjs/data esbuild eslint-config-prettier eslint-plugin-prettier

Unlisted dependencies (9)

Filename	unlisted
src/github/github-client.ts	@octokit/core @octokit/types @octokit/plugin-paginate-rest @octokit/plugin-rest-endpoint-methods @octokit/plugin-retry @octokit/plugin-throttling @octokit/auth-app
src/github/github-event-handler.ts	@octokit/auth-app
src/github/utils/config.ts	yaml

Unlisted binaries (5)

Filename	binaries
package.json	lsof awk
.github/workflows/build.yml	build
.github/workflows/bun-testing.yml	i
.github/workflows/cspell.yml	format:cspell

[whilefoo]

Every plugin will have its own DB and the kernel just calls plugins so it doesn't need any DB

[gentlementlegen]

Every plugin will have its own DB and the kernel just calls plugins so it doesn't need any DB

@whilefoo Understood, then what will happen with the current db, plain delete?
We can close this PR and just validate the issue as completed if you want, changes are already applied on the db side.

[0x4007]

The only useful data from the current database isn't really even worth migrating. It's just the wallet data. Instead we can just force everybody to re-register.

However we may also need to figure some type of standardized way to bus data from plugins to other plugins.

For example:

Wallet registration plugin /wallet stores wallets

Permit generation requires wallet data.

Technically we could make it the same plugin with two different intended entry points though. One for the slash command (comment created event) and then one to generate permits (invoked as part of a chain of other plugins, originally from issue closed as complete)

This might be the easiest way forward in the short term. In the longer term we can probably take inspiration from how Amazon web services was formed. Basically leadership forced the team to build internal systems with standardized modules and interfaces. Then they made those interfaces public.

[rndquu]

This PR corresponds to 2 bot plugins:

• registration (users and wallets tables), which is not created yet
• https://github.com/ubiquibot/permit-generation (permits and tokens tables)

I don't want to close this PR without merging since these DB migrations will eventually end up in plugins' DB instances. I think the best thing we can do right now is to merge this PR into the old bot's instance at https://github.com/ubiquity/ubiquibot

[gentlementlegen]

This PR corresponds to 2 bot plugins:

• registration (users and wallets tables), which is not created yet
• https://github.com/ubiquibot/permit-generation (permits and tokens tables)

I don't want to close this PR without merging since these DB migrations will eventually end up in plugins' DB instances. I think the best thing we can do right now is to merge this PR into the old bot's instance at https://github.com/ubiquity/ubiquibot

I am fine with that, I will move the PR to the other repository.

[gentlementlegen]

Pull request moved to ubiquity/ubiquibot#923