I am upgrading a Rails app from 4.2.x to 5.0.x. After I updated all my Rails-related gems in Gemfile, I ran the rails task for updating all my files to conform to the newest version, as per the upgrade guide:
rails app:update
There were many conflicts in this command, so I pressed a to accept all conflicts and then review them manually before committing them. My main concern is what happened to the config/routes.rb file. Basically, the entire contents of the file, save for the Rails.application.routes.draw block and a single comment about the DSL added to the end of the file, were kept. All routes that have been added to the app over the years were cleared out, not to be found in any other file.
This issue doesn't block me, I'll simply checkout the file to bring it back to its former state. However, what especially concerns me is that an essential file was cleared out in what appears to be a normal situation for upgrading a Rails version. I'd like to see if anyone else has run into this issue, whether this is expected, what's going on. Comments from Rails maintainers are welcome. Thank you.
The app:update task is just a slightly modified version of the task that creates a new Rails application. It writes out files under config/ and bin/ based on the templates from the new Rails version. If you selected a to accept all conflicts, then that simply means that Rails is going to overwrite any differing files with its own copy without asking you. This is normal and expected. If you don't want that behavior, then don't press a.
config/routes.rb is almost certainly the one file under config/ that will differ almost completely from the empty boilerplate file.
Realistically, Rails can't be expected to parse your custom changes and merge them with a new template.
For what it's worth, I like to start out doing exactly what you did, with a clean working directory just let the app:update task overwrite anything it wants to, and then go through all the changes with a side-by-side, SCM-aware diff tool like vim-fugitive to stage or discard the differences.
Well, just don't accept all conflicts, take a look in each one of it. Making version upgrades of 1 level of magnitude may change a lot of things and the process takes a while.
First take a look on the changes in the framework and do the process carefully. You may be breaking a lot more stuff that you are not noticing:
http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html#upgrading-from-rails-4-2-to-rails-5-0
Related
I initially created it in rails 5 with the --api tag.
From http://edgeguides.rubyonrails.org/api_app.html,
I removed config.api_only = true
I changed
class ApplicationController < ActionController::API
end
to
class ApplicationController < ActionController::Base
end
The problem I'm having now is when the view is getting rendered, ex. welcome/index.html.erb, the corresponding CSS file assets/stylesheets/welcome.css.scss is not.
Any idea how I can fix this, or more generally convert the API application to a full app?
Thanks!
I ran into this same problem and I believe I've solved it. I was hoping to find a simple rails generator to convert it, but unless I've missed something it's not that easy. However, rails does make it easier than doing it totally manually.
The key is that the rails new command can be used on an existing app. Note that this answer assumes you know how to use git and are using it on the existing app.
First and most importantly, make a new branch. This serves two functions, 1) so you shouldn't lose your work if you mess it up (although it still might be a good time to back it up, like to GitHub), and 2) so you can compare the files that have conflicts after this process and retrieve any work that this process overwrites (it wasn't much for me, but it was important).
In the terminal, from the directory of the app you want to change from API only to standard. Run the following commands to go up one directory and then have rails write a new project over your existing one. Use the same options on the second command that you used when creating your app initially. For example, for me I replaced [options] below with -d postgresql --skip-turbolinks --skip-spring -T because those are the options I used when creating my app. I'm using the --skip-bundle flag because it might change your Gemfile more than you want it too and you'll probably want to change some of it back before bundling.
$ cd ..
$ rails new your_app_name --skip-bundle [options]
Now rails is going to go through it's usual process of creating all the files for a new app, but this time it's going to skip almost all of them because they're already there. It will stop on each one on which there is a conflict, and that's where you'll need to analyze the conflicts one-by-one.
Here's what worked for me on the conflicted files:
Submit d on each one of them to see the differences.
If the difference is only adding lines, then allow it with Y. That's why we're doing this after all.
If the difference is only removing code, then reject it with n.
If the difference is both adding and removing code, write down that file to come back to after this process. Then accept it with Y.
After this is finished, use git to examine the difference on each file from (4) that you wrote down. You'll want to keep the changes that rails added, but then you'll likely want to copy all the code that it removed back in. This will probably include the Gemfile.
One notable difference is that rails changes the application controller from inheriting from ActionController::API to ActionController::Base. I want one controller for each, so I created a new file `app/controllers/api_controller.rb'. Then I copied what was in my original ApplicationController over to the new file and just changed the class name to ApiController. Then I changed all my existing API controllers to inherit from the new ApiController instead of from ApplicationController.
After that is done, then run bundle install to install the gems rails added into the app.
That worked for me. I hope it helps. Good luck!
From a directory outside of the api application (such as its parent - cd ..) I would do
rails new comparison_real_app
and then compare the contents of the comparison_real_app with your app and copy over the files that are missing into the api app and change any other files as required.
So there's probably more things that will need to be done as I (you) go along, but to resolve the issue with stylesheets you need to manually create your views/layouts/application.html.erb and assets/stylesheets/application.css files.
I am building a Rails plugin for an application at work.
I want to extract logic that was used in multiple locations, but implemented slightly differently, and add new features needed without doing it 2-3 times over.
I've never build a gem, but according to what I was reading it is possible to use rails generate.
However this has not been the case for me.
Running rails g model Something stuff:type:
First interesting thing is that it is generating mini test stuff when I explicitly told the plugin not to use mini test (using Rspec).
Then looking in my folder structure for the plugin, no db/ folder, nothing added to app/models/, and no test/ folder:
Running the command a second time reveals to me that the files are indeed created:
My questions are:
Where is this stuff going? Can I even find out?
Has anyone encountered something similar? Is it due to a misconfiguration, or bug? Essentially, what's happening?
I would truly appreciate any advice or suggestions!
EDIT #1
Forgot to mention that I checked within the spec/dummy application in case things were being created there, and it is still empty as I left it.
EDIT #2
So I found where the files were by using the find command:
And yeah it added the files to my home folder...
At least now I can just paste them in the right location, but obviously this is bizarre and I'd like to get this resolved, figure out what is going on.
Okay so turns out that yes you may use Rails Generators when building a gem. Also, the generated files will not be placed inside the dummy application unless you are in that directory.
Everything is working as expected on a different computer.
That stuff is going into dummy app that is usually located in test/dummy. In your case, it seems to be located in specs/dummy.
Yeap and nope. That's not misconfiguration.
I am just very confused by this conflicting thing. I do want to put webrat.log into my .gitignore so that I don't need to merge it every time. Yet I notice from Michael Hartl's Rails 3 tutorial book that webrat is a testing utility gem. So I really don't know whether I can ignore it.
Please help me, a newbie rails programmer.
For the most part, you should ignore every *.log file. They'll be deleted, modified, whatever every single time you run anything, and unless you really need them to be under control, they shouldn't be.
(And you basically never need them under source control.)
I have a large rails project currently using rails 2.3.11 and I want to migrate it up to rails 3. I had an idea that I'd like to try but I need some git help.
What I want to do is start from a fresh new rails 3 app. One idea is to get in my current rails project directory and delete everything. Then do a commit so the tree is empty. Then create a new rails 3 project. This way I am starting fresh so everything will be current.
Then as I add the old controllers, etc back into the project, I want to "unrm" them. Git knows the history of the files and I'd like to keep that history.
Another alternative would be to start a fresh rails 3 app and then somehow transport files from the old git repository to the new git repository but I'd like to keep the history of the file.
This is a half baked idea but it seems a more viable approach to moving this particular project is to essentially start over fresh and then move things from the old project into the new project. But when I move things from old to new, I'd like to keep the history of each particular file.
Can anyone suggest a method of doing what I've just outlined?
First: check out this to automatically find some of the things that need to be upgraded: https://github.com/rails/rails_upgrade
To answer your question: You can upgrade your rails gem and then run rails new . to generate a new rails 3 app on top of your rails 2 app. It will clobber a few of your important files, but you can use git diff to figure out what was in them and copy the important things into the new file. Finally, there's a few things you might need to manually delete (like all of the files in the script/ folder except for rails). "Generating" a new rails 3 app on top of your existing app seems to be the recommended practice, and worked well for me when I upgraded a rather large and old app.
Is it even worth it?
I'm working on assessing a legacy code base for a client -- the source code has been largely untouched since 2007 and it's built with Rails 1.2.3.
My Rails experience began at version 2.1 -- the code is fairly stock/scaffold like and devoid of meaningful tests -- I was curious to even see if I could get it running locally -- but, I'm not even sure where to start. Right off it doesn't even know what 'rake db:create' means. Ha!
Is it going be a major pain to even getting it running in 2.3.5? Should I bother?
Would love to hear your thoughts.
Thanks
If you're going to be actively developing the site, then yes, it is worth sinking the time into the project to bring it up to date. A lot has happened since Rails 1.2 which will make development a much more pleasant experience. Life without named scopes or RESTful resources is really difficult. If you're just patching the odd thing here and there, it may be worth leaving it mostly as-is and just dealing with the eccentricities.
Since 1.2.3 is just prior to the releases building up to 2.0 where a lot of warnings and deprecation notices were introduced, you could have quite a chore.
Some things to keep an eye out for:
Migrations are now date-tagged, not numbered, but are at least backwards compatible
Many vendor/plugins may not work, have no 2.x compatible version, or need to be upgraded
The routing engine has changed, and the name of many routes may have changed, so see what rake:routes says and get ready for a lot of search-and-replace
I did this for a client with a smallish site. First, version control is your friend. Make sure you have the entire codebase committed.
Next, the basic recipe is as follows
Tag the current source
Update to the next release of rails (you'll have to google for the release announcement). My app was frozen, so I just had to freeze to that version
rake rails:update to update the config, scripts and js
Diff your working copy against the version in your scm. Make any changes necessary for the app
Update any gems/plugins if necessary
Start the app, exercise and test. Look for deprecation notices
When it all looks good, commit to scm and tag
Lather, rinse, repeat
For my client's app, it was much easier than I thought.