-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Copy new migrations as part of the update task #4957
Conversation
Codecov Report
@@ Coverage Diff @@
## master #4957 +/- ##
=======================================
Coverage 86.68% 86.68%
=======================================
Files 578 578
Lines 14684 14687 +3
=======================================
+ Hits 12729 12732 +3
Misses 1955 1955
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @kennyadsl!
Did you try to add a test for the new behavior? That generator is tested and it'd be good to add it. However, if that's going to require a complex setup (which I'm afraid could be the case) I'm also ok with not doing that.
@@ -40,7 +40,7 @@ class UpdateGenerator < ::Rails::Generators::Base | |||
def create_new_defaults_initializer | |||
previous_version_prompt = options[:previous_version_prompt] | |||
return if previous_version_prompt && !yes?(<<~MSG, :red) | |||
The update process is only supported if you are coming from version #{FROM}. If this is not the case, please, skip it and update your application to use Solidus #{FROM} before retrying. | |||
The defaults update process is only supported if you are coming from version #{FROM}. If this is not the case, please, skip it and update your application to use Solidus #{FROM} before retrying. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The defaults update process is only supported if you are coming from version #{FROM}. If this is not the case, please, skip it and update your application to use Solidus #{FROM} before retrying. | |
The default update process is only supported if you are coming from version #{FROM}. If this is not the case, please, skip it and update your application to use Solidus #{FROM} before retrying. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was actually defaults
. It refers to new_solidus_defaults
. I'll try to see if there's a way to make it more clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed to "The default preferences update process..". Thoughts?
I didn't remember we have tests for that task, thanks for pointing out. I'll definitely try! |
@waiting-for-dev I'm losing any hope that we can test copying the migrations. My only idea was to remove the last existing migration from the dummy app in the test setup and then run the update task to see it generated again. But this won't work because the dummy app actually doesn't hold any migration; they are used directly from the engine, injected programmatically in the App via |
Right now, we are not copying the new migrations introduced with the new version. This new install step will copy migrations and it's left to the user to run db:migrate, before checking them. This commit also update some copy of the task to reflect the new content of the file.
0886241
to
241f6bc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@waiting-for-dev I'm losing any hope that we can test copying the migrations. My only idea was to remove the last existing migration from the dummy app in the test setup and then run the update task to see it generated again. But this won't work because the dummy app actually doesn't hold any migration; they are used directly from the engine, injected programmatically in the App via config.paths['db/migrate'].
No worries. The only clean way I can think would be to have the install:migrations
accept an injectable directory and use tmp/
for the tests, but that comes from Rails.
Nice work!!
@@ -57,6 +57,11 @@ def create_new_defaults_initializer | |||
File.join(options[:initializer_directory], "#{options[:initializer_basename]}.rb") | |||
end | |||
|
|||
def install_migrations | |||
say_status :copying, "migrations" | |||
rake 'spree:install:migrations' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using spree:
as the namespace is even better than using the FROM
env variable 👏 👏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, sorry, I thought I had already approve this one 👍
💚 All backports created successfully
Questions ?Please refer to the Backport tool documentation and see the Github Action logs for details |
Summary
Running
bin/rails solidus:update
, we are not currently copying the new migrations introduced with the new Solidus version. This new install step will copy migrations and it's left to the user to rundb:migrate
, before checking them.This commit also updates some copy of the task to reflect the new content of the file.
Checklist
Check out our PR guidelines for more details.
The following are mandatory for all PRs:
The following are not always needed: