shopozor/services

How not to commit the fixtures placed in `migrate` dir to the repo ?

Closed this issue · 2 comments

When you generate fixture data, special migrations are generated in the migrations directory. But how not to commit those to the repo ? They should certainly not be commited or should they ? The problem is that if you want to checkout an other branch to do stuff, you are stuck with

database-service@LAPTOP-RKV9BPCA[[dev ?]]$ git status
On branch dev
Your branch is up to date with 'origin/dev'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        ../Pipfile
        migrations/1572639052922_shopozor-consumers.up.sql
        migrations/1572639052975_shopozor-producers.up.sql
        migrations/1572639053031_shopozor-managers.up.sql
        migrations/1572639053084_shopozor-rex.up.sql
        migrations/1572639053137_shopozor-softozor.up.sql

nothing added to commit but untracked files present (use "git add" to track)

It is not particularly appropriate to do a git stash or a git clean -n just to checkout another branch. These fixture data should be ignored by git.

The more I use this system, the more I think that fixtures should be something separate from hasura migrations that does not conflict and interact with normal hasura migrations.

We could probably generate a separate directory completely ignored by git, for example something like fixtures/migrations. To load fixtures data, one has just to cd into fixtures/migrations and make a hasura migrate apply.

What do you think ? Could that work. That way, we could perhaps even commit the fixtures to the git repo once for all, all in sync with the database structure in order to facilitate tests and development.

A possibility of handling this could also to copy the migration files into the test container and not putting on the host system at all

So to answer the original question: how not to commit the generated migration files for the fixtures? it's pretty easy: you don't add them to your commits.

Where I do agree with you is that it is not clean. They should be ignored somehow. I'll put some thoughts into your proposition. You can also try on your own in a separate branch where you would just try another structure. I think your proposition to put the migrations in a folder like fixtures/migrations is probably a good idea. I don't know if hasura will be happy with that though. I don't know if you can have several hasura projects and use them together (we have our database-service and we would have the fixtures-service additionally). You can try and see what would happen.