Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Store checksum of previous migration in each migration #29

Open
JanTvrdik opened this issue Nov 2, 2015 · 4 comments
Open

Store checksum of previous migration in each migration #29

JanTvrdik opened this issue Nov 2, 2015 · 4 comments

Comments

@JanTvrdik
Copy link
Member

The migrations:create command would instead of empty file create file with first line containing reference to parent migration, e.g. sth like

# parent = structures/2015-08-28-142150-init.sql/786340a54b68591563e983f60f82fecc

This will allow us to detect when programmer forgot to „rebase migrations“. This would also probably required some tool to help with the rebasing etc.

@hrach
Copy link
Member

hrach commented Nov 2, 2015

Great! I was thinking about similar solution of storing such thing into separate file... :)

@Mikulas
Copy link
Contributor

Mikulas commented Nov 3, 2015

👍 It would be handy to have a migrations:rebase tool then though, creating those headers manually after rebase would be huge pain.

Also it can't be integrated into old migrations easily as their checksum would change.

@hrach
Copy link
Member

hrach commented Dec 11, 2015

I have a different idea. What we want is the security, that prevent's us from merging pull request if it contains migrations which is not the last. Such check may be done by CI server that run your test suite on the merge commit. However, the current proposed solution does not solve this, if the test suite (and migraiton command) is not run on the merge, just on the head of branch (=current CircleCI's behavior).

My idea is the following:
store in some file the last migration name (or hash, but name is independent on the migrations contents and therefore no regeneration is needen, also, it's more explicit) and any pull-request would fail by merge conflict, if you try to merge migraiton which is not the last. Then, rebase on the master head would be needed.

What do you think?

@Mikulas
Copy link
Contributor

Mikulas commented Dec 11, 2015

That would work, but it could lead to false sense of security with git rerere enabled (it would resolve the conflict but keep the new migration not-rebased). Other than that I don't see a problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants