Storyblok CLI - migrations - run against other spaces

[edvinasjurele]

It seems I can't find a way to run migrations against multiple spaces with the current setup. We have a 3-space structure (DEV, STAGING, and PRODUCTION), where migrations are typically created and tested against the DEV space first. Once validated, they are run against STAGING, and finally PRODUCTION, either via CI/CD or locally.

In the old v3 CLI (reference), migrations were organized into a folder like so:

migrations
  change_{block-name}_{field-name}.js
  change_{block-name}_{field-name}.js
  change_{block-name}_{field-name}.js

This allowed us to run migrations against any specified space by pointing the command to the desired space. Typically, we executed them locally on DEV first, followed by STAGING and PRODUCTION through CI as part of our release pipeline.

In the new CLI version, the usage seems very similar:

storyblok migrations run --space {SPACE}

However, the --space flag is used to both read migrations from and execute them on the same space. This does not align well with our workflow, as it would require physically duplicating the migration files into separate folders assigned to different space IDs. This duplication feels excessive and unnecessary, as it complicates the process just to accommodate cross-space execution.

I initially thought the --path option would solve this issue, as I assumed it would allow specifying the exact directory or full path of migrations to use. However, it turns out --path serves only as a base path, not a fully customized path to source migrations from.

Do you have any suggestions on how we could achieve cross-space execution without duplicating migration files? Ideally, we'd like a way to keep a single set of migration files and execute them against multiple spaces (DEV, STAGING, PRODUCTION) as needed.

[edvinasjurele]

@alvarosabu @imranolas any resolution here? I find this as a major blocker for us, as we use multi-space setup.

We can run datasources/components pushing cross-space, but weirdly migrations can't 🤔

[alvarosabu]

Hey @edvinasjurele, at the time of the design of the migration command, we didn't have any feedback from other users about this use case, so that's why we didn't include it, but I think it is reasonable since we also allow it on other commands. Maybe adding a --from flag to be consistent.

As a workaround to avoid a blocker, you can potentially do cp -r .storyblok/migrations/space-a .storyblok/migrations/space-b before running the migration

I will discuss the feature with the team, thanks

[edvinasjurele]

Hey, thanks. Yes --from flag seems consistent for sure.

Unfortunately, the workaround doesn't work because we are upgrading the CLI within our own CLI. This means we will need to manage CI flows and write code to duplicate migrations across folders, which is not an ideal solution (though locally, this is the way to go and I am aware of it 🙌 ). For this reason, I see this functionality as the only blocker preventing us from finally upgrading the CLI to v4 in our project.

[edvinasjurele]

Hey, I just wanted to follow up on this. Are there any not-so-distant future plans to extend this functionality? For now, I’ll try my best to patch this behavior on our side by physically duplicating the migration file to the correct folder and then deleting it right after the command is executed. It sounds doable, but it’s certainly not an elegant solution. This might be the last thing we need to fully migrate to Storyblok CLI 🙈

[dipankarmaikap]

@edvinasjurele Thanks for bringing this up earlier. Just wanted to give an update that this has now been addressed in the latest version of the Storyblok CLI. The feature is included out of the box, so updating to the newest release should resolve it.

If you run into anything unexpected after upgrading, feel free to reopen or start a new discussion.

[edvinasjurele]

Thanks @dipankarmaikap, I will check it out 🙏