Good DX for git

[elitan]

Git branches

Postgres / Hasura does not play well with different git branches out of the box.

Imagine the following:

1. Clone a repo with existing Nhost project
2. [main] start nhost dev
3. [main[ Postgres, Hasura, etc starts and applies migrations and metadata
4. [new-branch] checkout [new-branch]
5. [new-branch] Add table and edit some metadata
6. [new-branch] commit changes
7. [main] Goes back to main branch
8. OUT OF SYNC

In step 7 when the developer goes back to main from new branch the database still has the changes from new branch. If the developer after step 8 does any change in Hasura, the Hasura CLI will save the metadata changes that were created in new branch.

Ideally, every git branch should have its own isolated database and the developer should seemingly be able to checkout different branches and the CLI should make sure that the database is up-to-date with whatever branch the developer is at.

Proposed solution

The CLI keeps track of the active branch and creates a separate folder inside .nhost for each branch. Ex:

.nhost/main/[db_data/custom/minio]
.nhost/branch-1/[db_data/custom/minio]
.nhost/branch-2/[db_data/custom/minio]

And whenever the developer switch branch the CLI should:

• automatically switch Postgres database
• update volumes for Hasura Auth (custom folder for email templates)
• update Minio volume

---

Git pull

Imagine a developer work locally in the main branch and have nhost dev running. They then do git pull and their co-workers have updated some migrations and metadata. After the git pull the developer's postgres/hasura is out of sync. After git pull the developer has to run hasura migrate apply and hasura metadata apply to get their postgres/hasura in sync again.

This is however easy to forget.

Ideally the CLI should keep track of this and apply these migrations and metadata changes automatically after a git pull to make sure that the code (migrations/metadata) and the database/api (postgres/hasura) are always in sync.

Maybe this out-of-sync problem is not only isolated to git pull?

Possibly solution

CLI should run hasura migrate apply and hasura metadata apply automatically after git pull. Possibly by keeping internal information about the git log and run apply commands when the current commit changes.

[mrinalwahal]

Please checkout version v1.0-internal-16.

It enables the following:

1. Restarts your environment on git checkout. Along with mounting the new .nhost/{{branch_name}} path for both minio and postgres.
2. Re-applies migrations and metadata on git pull/merge/fetch.
3. Once you change branch, the CLI will also automatically start watching the new branch for commit changes (on pull/fetch/merge). Use the --debug flag to check the logs for these new files being added to the watcher. And if you changed back to a branch which already had a watcher attached, no new watcher will be added.

There are possibilities of bugs. So, do let me know.

Git checkouts worked fine for me even on repeated attempts. Attached screenshot below.

Git pull worked fine on initial carousal look. Attached Screenshot below.

[elitan]

I ran into an issue where the Hasura CLI does not seem to work correctly. I made a video here:

https://www.loom.com/share/21d7ecbf1dfe4552aee70fb2aa936c1d

[elitan]

Another corner case:

1. checkout new branch
2. nhost CLI starts applying changes
3. before nhost CLI finishes applying changes, do git pull and pull new migrations.
4. nhost CLI does not pick up new changes because it was busy applying changes from step 1 but there are new migrations from step 3.

[mrinalwahal]

This is a race condition.

Here 's my solution:

I will let environment become active again after git checkout, let it apply it's migrations, and then perform the migrations it was supposed to - after pull/merge/fetch.

If the user pulled code BEFORE the environment performed the migrations (i.e. during health check stage) it was supposed to, then Hasura CLI will apply the migrations that came AFTER pull.

And if the user pulled AFTER the env had already performed it's migrations, and Hasura CLI won't re-apply the same migrations, even if we run hasura migrate/metadata apply, because under the hood, it first checks whether the migrations it's applying already exist or not.

As complex as this solution sounds to be implemented from my end, it's equally complex for the user. Because it can break the user's own migrations. If we applied newly pulled migrations BEFORE the original migrations of the "new" branch after checkout.

[mrinalwahal]

@elitan The Hasura Console <> Hasura CLI issue should be solved in v1.0-internal-18. Do check it out and let me know!

Heads up! Nhost CLI will no longer re-launch Hasura console and Mailhog tabs in your browser just because you did git-checkout/pull/merge/fetch. You can continue using the earlier ones.

I've also implemented the aforementioned solution for the race condition problem. I'm yet to test that solution, though! Will work more on it tonight.

[elitan]

I guess we can close this issue for now? The CLI works as intended for git branch changes and git pull