`gel project init` applies migrations against the wrong branch

[kristojorg]

When running gel project init to link to a cloud instance, it will prompt you which branch you wish to use. The language here is actually a bit confusing, it just asks you for the Specify branch name: [default: main]: , which I think is asking which branch you wish to connect to initially. However, no matter what you choose, it will run migrations against the default branch, which is quite dangerous when connecting to a production cloud instance.

• EdgeDB Version: "6.1+a41b539"
• EdgeDB CLI Version: Gel CLI 7.0.3+79e11b7
• OS Version: Mac OS Sequoia 15.3.1

Steps to Reproduce:

Repro repo: https://github.com/kristojorg/quickstart-nextjs

Setup

1. Clone the repo. It has a schema and some migrations defined
2. Create a new cloud instance
3. Connect to the cloud instance without running migrations and create a second branch called "dev":
   • gel project init --no-migrations - there is no way to create a branch without initializing a project it seems
   • Follow prompts to connect
   • gel branch create dev
4. Unlink the project gel project unlink

Now we reproduce the bug

5. Link to the cloud instance and choose the dev branch:
   • gel project init
   • select the dev branch you created when it asks Specify branch name: [default: main]:
6. Observe that it runs some migrations. I expect these to be run against the dev branch we selected...
7. Check the current branch gel branch current - it should say dev
8. gel describe schema - it will be empty though it should have received the migrations
9. gel branch switch main
10. gel describe schema - it will erroneously have the migrations that should have been applied to dev

What's wrong with this

The workflow I am using is to develop against a branch on my production cloud instance (for the time being). I needed to switch to a local instance recently to reproduce a bug and check the postgres logs. So then when I switched back to the cloud instance, I used gel project init and specified the dev branch but all of my in-development migrations were run against my main production branch :/ .

An aside about project init

I believe there should be a separate, inert command to link the CLI to an instance without executing any migrations. I know there is --no-migrations, but this is easy to forget and can easily result in production data loss. I would propose gel project link that simply links to the specified instance.

Separately, I think that gel project init should ask/confirm before executing migrations against the instance you are connecting to. @scotttrinh brought up that this might be confusing for beginners using gel project init while getting set up, but I am not sure it would be. If you are getting set up for the first time and have migrations to run in your project (for example you are in an example repo), asking "Would you like to run the following migrations to migrate this instance to match your project?:" would make sense for a new user.

[1st1]

@vpetrovykh can you test this?

[vpetrovykh]

OK, first things first, it is a good idea to upgrade the gel CLI. Run: gel cli upgrade --to-stable In the ver 7.6.0 the interactive mode for gel project init should correctly connect and apply the migrations to the branch you specify in the prompt.

Also, you can use the old -d <branch-name> command line argument when you run gel project init to correctly connect and apply changes to the desired branch (instead of the default). It will complain that it's the old style of argument, ignore that, it appears that the new style -b is bugged for gel project init.

This should at least enable you to work around the bug.

[vpetrovykh]

I can confirm that for older version (7.0.0) the interactive mode of gel project init ignores the user-specified branch for cloud instances and does not even ask to provide a custom branch name for local instances.

This inconsistency seems to be fixed in the later version (tested on 7.6.0).

[vpetrovykh]

There still is a bug with providing custom branch name to gel project init, though.

Specifically, if you use the "updated" flags for branch: -b:

$ gel project init --link --server-instance vpetrovykh/barracuda -b woot --non-interactive
Found `gel.toml` in /home/victor/dev/migbug
Linking project...
Applying migrations...
...

A new branch edgedb is created instead and that's where the migrations are applied.

The same issue arises for local instances as well. The -b flag is ignored.

However, the older (and to be deprecated) flag -d works fine for both cloud and local instances.