Track all future CI / CD workflow updates

[melvinchia3636]

This issue will serve as a master tracker for all future tasks, improvements, and updates related to the CI / CD workflows in this repository.

Please link any new or ongoing issues, pull requests, or discussions related to CI (Continuous Integration) and CD (Continuous Deployment/Delivery) here.

Examples of topics to track:

• Adding, updating, or refactoring GitHub Actions workflows
• Integrations with CI/CD tools (e.g., GitHub Actions, Jenkins, CircleCI)
• Improvements to build, test, or deployment automation
• Security enhancements in pipeline workflows
• Documentation related to CI/CD processes

Feel free to comment below with suggestions or links to related issues.

[ahmed2m]

Do you mind sending me an export of your collections schema, as of now. By using pocketbase migrate collections this would generate a migration file a newly created directory pb_migrations.

Here's what I am thinking, just like every db system, it's a best practice to do the following:

• Keep the generateCollectionsSchemas thing for type generation.
• In the source code, along with checkDB logic maybe execute a command (actual shell command running ^{^1}) to run these migrations.
• With every schema change (new collection or field change) create a migration file.
• With every schema change users are expected to restart the server (because it would be a version update) so the migration command would also migrate their PB database before starting the server.

You mentioned before a problem that users have to "install" and "uninstall" modules and that complicates things for db schema? I don't get why though, you don't have to build the db on demand. Every user gets the same PB collections and you can add a field in their profile to indicate which schemas are enabled and which are not.

Keeping migration files in Git and updating them alongside schema changes is both more practical and reliable. Relying solely on rebuilding schemas from types and committing them manually with the SDK is just adding unnecessary risks and development overhead. With the native migrations, we stay aligned with PocketBase’s own changes, reducing the chances of unexpected issues (although PocketBase is not at v1.0 yet, worst case scenario when PB introduces breaking changes we will use their migrations guides rather than stitching together an adhoc solution)

There could be a CI check for PRs with a pocketbase image (would run the migrations automatically) and it checks the schemas.ts (current checkDB functionality) so if the developer who's adding collections/fields forget to run pocketbase migrate collections the CI would remind him.

^1:
Something like
For node

async function runPB(cmd: string[], cwd = process.cwd()) {
  const bin = process.env.PB_BIN ?? "./pocketbase";
  const { stdout, stderr } = await execFileAsync(bin, cmd, { cwd });
  if (stderr) process.stderr.write(stderr);
  process.stdout.write(stdout);
}

(async () => {
  await runPB(["migrate", "up"]);
})();

or
For bun

import { $ } from "bun";
await $`${process.env.PB_BIN ?? "./pocketbase"} migrate up`;

[melvinchia3636]

Do you mind sending me an export of your collections schema, as of now.

Here you go: https://gist.github.com/melvinchia3636/8406333b029140a803276bf53391325d

[melvinchia3636]

Here's what I am thinking, just like every db system, it's a best practice to do the following:

* Keep the generateCollectionsSchemas thing for type generation.

* In the source code, along with checkDB logic maybe execute a command (actual shell command running ^1) to run these migrations.

* With every schema change (new collection or field change) create a migration file.

* With every schema change users are expected to restart the server (because it would be a version update) so the migration command would also migrate their PB database before starting the server.

This approach sounds pretty promising. It would be amazing if you could help with the implementation. Feel free to hit me up if you need anymore context or clarifications.

[ahmed2m]

Any clue why the app looks like this? Is there some static i18n strings setup that should be setup?

Screenshots

[melvinchia3636]

I can't seem to reproduce the issue. Can you see if you are up-to-date with the latest commit? If so, is there is any error in the browser console?

[melvinchia3636]

You mentioned before a problem that users have to "install" and "uninstall" modules and that complicates things for db schema? I don't get why though, you don't have to build the db on demand. Every user gets the same PB collections and you can add a field in their profile to indicate which schemas are enabled and which are not.

After reading your words again, I think you might have some misunderstanding of the modularization approach that I am planning to implement. In the future, I'm actually going to build some kind of module store (just like the Google Play Store where you can install and uninstall apps) where user can choose which module to download and install into their system. Therefore, we might end up with hundreds of different modules available, which means keeping all the collections required by every single module inside the database is not practical, and there must be some sort of dynamic way to determine which collection should be present in the database.

[melvinchia3636]

Alright, after losing quite a decent chunk of my brain cells, I've got the modularization mechanism mostly implemented. All the modules have been removed from the main codebase and will be added back as individual repos in Lifeforge's organization. Documentation will be updated within this week, and guides for installing and managing modules will be added.

[melvinchia3636]

See 0d651e4 inside apps directory if you wanna take a look at how each module is structured, all commits after that already have the modules separated.