I found a bug in the autogeneration process of migrations.
Reproduction path
This reproduction path assumes youāve just created a new blank datocms instance without having made any changes to the primary env. It also assumes you have the datocms cli installed and configured. This is what my datocms.donfig.json
looks like:
{
"profiles": {
"default": {
"logLevel": "BODY",
"migrations": {
"directory": "./datocms/migrations",
"modelApiKey": "schema_migration"
}
}
}
}
Autogenerating migrations fails when the primary env is empty
(due to not being able to diff, might also be a bug?).
So create a āSchema migrationā (schema_migration) model in the primary env.
Add the following single-line string field to the model āMigration file nameā (name) and make the field required under the āvalidationsā tab.
1. Create a fork of the primary env called āfeatureā.
$ npx datocms environments:fork main feature --json --api-token=YOUR_DATO_API_TOKEN
2. Make changes to the āfeatureā env in datocms using the website UI.
a. Go to datocms and switch to the āfeatureā env .
b. Create a new model called modelA
(settings > models > add new model > enter modelA
as the name > save model).
c. Create another new model called modelB
(settings > models > add new model > enter modelB
as the name > save model).
d. You should now have a content
tab in the top nav bar and when clicked you should see the following 4 menu items: Schema migration, modelA, modelB, Settings
(in that particular order).
3. Generate a migration file for the changes you just made in the āfeatureā env.
$ npx datocms migrations:new myMigration --autogenerate=feature:main --json --api-token=YOUR_DATO_API_TOKEN
4. Create a second fork of the primary env called āfeature-testā.
$ npx datocms environments:fork main feature-test --json --api-token=YOUR_DATO_API_TOKEN
5. Run the generated migration file against on the āfeature-testā env.
$ npx datocms migrations:run --source=feature-test --in-place --json --api-token=YOUR_DATO_API_TOKEN
This works fine and does exactly what it needs to
Moving on to the bugā¦
6. Delete the āfeatureā env.
$ npx datocms environments:destroy feature --json --api-token=YOUR_DATO_API_TOKEN
7. Delete the āfeature-testā env.
$ npx datocms environments:destroy feature-test --json --api-token=YOUR_DATO_API_TOKEN
8. Repeat the process, but this time with an extra change.
Repeat steps 1-5, but add steps 2e and 2f before step 3.
2e. Change the order of the menu items in the ācontentā tab. Change the order from Schema migration, modelA, modelB, Settings
to Schema migration, modelB, modelA, Settings
(essentially switching modelA and modelB in the order).
2f. Delete the generated migration file (manually in the IDE) THIS IS VERY IMPORTANT
When you have completed step 5 againā¦
You should see be able to verify in your cli that the migration failed:
{
"error": {
"message": "Migration \"1673011341_myMigration.js\" failed",
"oclif": {
"exit": 2
}
}
}
Other notes
After some digging I found out that the reason the migration fails is because of this line (note: the ID ā569389ā will be different for you):
await client.menuItems.update("569389", { position: 3 });
There are no records/menuItems with ID ā569389ā making the migration fail in the process. (It seems like menuItem IDs are outdated if you ever generate a new migration file after already having created one once in the same dato env).
This is the simplest reproduction path I could come up with, but you can also get this bug without intentionally changing the menu item order; when you have multiple models, deleting one of the models can cause a āshiftā in menu items also causing this bug to occur.