New split repo - manageiq-ui-classic

We have just completed another HUGE repo split. This time the UI team has extracted the ManageIQ classic UI code into the repo. Coming along for the split are all of the UI specific specs as well as the javascript test suite.

If you would like to contribute to the UI code, now it should be much easier for you to create Pull Requests in this isolated repo. @himdel has written up some instructions on how to get started on developing in this new repo. The instructions are at and he will be updating as things progress.

If you have any questions, please ask them here.


Created a PR adding instructions on how to move pull requests over to manageiq-ui-classic:

EDIT: the PR is merged, so…

[RESOLVED] Heads up: any relative :path in manageiq/Gemfile will confuse bundler run from in the manageiq-ui-classic/ dir, with unhelpful messages, e.g.:

~/m/manageiq-ui-classic (master)> bundle install
The path `/home/bpaskinc/miq/manageiq-ui-classic/manageiq-gems-pending` does not exist.

Sure, it doesn’t, but why did it expect manageiq-gems-pending under the ui dir?!
The error actually comes from me having this line in manageiq/Gemfile:

gem "manageiq-gems-pending", ">0", :require => 'manageiq-gems-pending', :path => '../../manageiq-gems-pending'

=> Either only use absolute :path, or apply [MERGED]

For anyone who followed original instructions and is now getting bundle error:

[!] There was an error parsing ``: You cannot specify the same gem twice coming from different sources.
You specified that manageiq-ui-classic (>= 0) should come from source at `.` and source at `/home/bpaskinc/miq/manageiq-ui-classic`
. Bundler cannot continue.

[OUTDATED AGAIN] Solution: Update manageiq/ to do gem "manageiq-ui-classic" conditionally, as shown in current

1 Like

Ok, is in place, then because I had to refresh my test environment (openstack reset) I ran bundle exec rake db:drop. While running bin/setup, it fails.

== 20150224192447 AddProviderIdToEms: migrated (0.0006s) ======================

rails aborted!
GoodMigrations::LoadError: Rails attempted to auto-load:


Is the approach wrong?

Hi, we have a bugfix , but according to the comments it will be reworked.

Anyway, the easiest workaround you can use $ GOOD_MIGRATIONS=skip any_rake_task (ie. in your case rake db:drop)

Hopefully, it helps you :wink:

Thanks @jzigmund that’s what I was missing.

Just to clarify, I suppose until that’s been addressed it doesn’t really make sense to bin/update when coming from an existing running environment/test set since the migration is not executed. That’s okay just have to run bin/setup directly from a clean slate, if I’m correct.