DatoCMS CLI env variable usage for Environment names

✋ Feature Requests
1

(Moderator note: Copied Github issue text to the post body here to make the idea more easily readable / discussable)

The idea

As the CLI is already reading out the DATOCMS_API_TOKEN, would it be an option to use DATOCMS_ENVIRONMENT to use if available for the --autogenerate command?

Bonus points to use a third env variable DATOCMS_ENVIRONMENT_SOURCE from which the user can tell the CLI the fork has been created.

The potential way of working

So the CLI would run something like this automagically when env vars are available:

npx datocms migration:new someMigrationFileName --autogenerate=$DATOCMS_ENVIRONMENT:$DATOCMS_ENVIRONMENT_SOURCE

Reasoning behind the idea

When developing in larger teams it might happen that you create new features and new DatoCMS environments async and create new environment on a frequent basis (especially with continuous deployments).

When one developer brings their changes to main and deploy it to a new environment, the other developers still might need to generate their migration based on an older environment. If they in this case forget to set the source environment, they will end up generating a migration, removing all new fields/models/blocks that have been brought to primary environment.

This feature would make that process slightly less error prone :v:t2:

Original post:

I did not know if I should add this inside the git repository or here so I created this issue in GitHub and post it here :v:

2

@thomas.verleye, thank you for the suggestion! That makes sense and I hope we can add something like that.

As a short-term workaround before that is implemented, though… assuming your developers work on relatively isolated machines/instances (where polluting the global env isn’t an issue), might a command like this work to accomplish something similar?

source .env.local; npx datocms migration:new someMigrationFileName --autogenerate=$DATOCMS_ENVIRONMENT:$DATOCMS_ENVIRONMENT_SOURCE

That would just load the env file into the shell’s actual env vars and npx should be able to parse them directly… It’s not as clean as an isolated env file parser, but it should be OK if the devs don’t use those same env vars for different projects in the same shell.

3

Nice one @roger I tested this out myself and it works, I created following npm script in our package.json:

{
  "scripts": {
    "generate": "source .env; npx datocms migrations:new --autogenerate=$DATOCMS_ENVIRONMENT:$DATOCMS_ENVIRONMENT_SOURCE",
  }
}

This way we can easily run following command:
npm run generate -- someMigrationFileName

I’d like to point out as well that my command in the example and your example missed an s of migrations :slight_smile:

1 Like