geldata / geldata/gel-cli

`gel project init` applies migrations against the wrong branch

Open
#1,525 4 comments 2 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
175
Forks
32
PR merge metrics
No merged PRs in 30d

Description

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.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.