v1.x Migration Survey [for everyone] #339
Comments
|
First of all, great plugin and thanks for your hard work. My migration was not smooth, but I finally got it going. There was some corruption in my gitolite admin repo and it didn't occur to me to rescue everything which cleared it up (git fsck was clean, but redmine/plugin had something diff). It happened during the ssh key renaming. If possible, I'd suggest folks do a rescue before shutting down redmine for the migration. Just some small things - in the SCM list, Gitolite shows up as Xitolite. Also, I can't seem to get that nice 'how-to' for an empty repo anymore. I get a 404 "The entry or revision was not found in the repository." Although, the prepopulating with a readme works fine. Thanks again! |
It's normal. It's the Ruby class name for Gitolite repositories. I would have named it Gitolite but there is a class name conflict with the Gitolite gem we use to access to Gitolite Admin repository. So it's a small workaround but it worth it ;)
Fixed in v1.x branch. |
|
I ran into the following exception when running redmine_git_hosting:migrate_to_v1: Turns out I had an orphaned repository (project_id was 0). Not sure how this happened and it was a test repository that was never used so I deleted the record and everything ran fine. Might be worthwhile to add a condition to check. |
|
rugged installation requires pkg-config (Ubuntu Trusty: apt-get install pkg-config) |
|
After rugged installation failed, due to a missing dependency, I'm now running into the following error: Running |
|
👍 Worked fine for me since I've understood that my Debian/Wheezy Fortunately, I had redmine backups so I was able to begin again the migration from a good state with the right bundler version and all worked like a charm. The last issue I had was I didn't notice that after migration Redmine had the new Thank you and keep the good work :) |
|
Hi! I tested new redmine for future migration а week ago and did update git plugin to 1.0-beta. I found solution for few problems in this issue-tracker, but for one problem I spent a hour of my life. I use container virtualization (lxc, openvz) and usually have only base system after create a new virtual machine. I installed all dependencies in operation system for all ruby gems with 0.7.x plugin version. Everything worked fine (I use ssh://git@ for access to repos). Version 1.0 uses 'rugged' gem, and this gem was compiled without ssh support, because I have no install libssh2-1 and libssh2-1-dev so my installation was broken. All works again after installing libssh and recompiling gems. (Tests was performed on ubuntu 12.04 in lxc and ubuntu 14.04 in openvz) |
|
bundle install hangs on: and takes 100% of the CPU. same on v1.x branch. also note that the directions do not use the proper tag naming convention ( |
|
@anarcat > also note that the directions do not use the proper tag naming convention (v1.0.0 vs 1.0.0) for the main repo. Fixed. |
|
@anarcat I had same issue and I've resolved it by updating my bundler gem (before I used the Debian one and it was too outdated) Which version of bundle do you use ? |
|
@Trim the debian one... :/ maybe pre-requisites should be clarified here? |
|
#287 is a big problem, as it requires lot of recovery work and notify all users about changed paths, besides from that all went Smoth. |
|
I'm still using 0.7.10, waiting until rugged-0.22.1 (my distribution hasn't packaged 0.21.4, just jumped straight to 0.22) and redmine_git_hosting-1.0.1 is released :) |
|
I had problems with indexes while migration. here is my solution: drop index index_repository_git_extras_on_repository_id on repository_git_extras; |
|
For some magic reason, I can see, clone and push to existing repos, but when I try to create one, I can only have a "git" type and I have to submit some path. No Xitolite... Strange... I cannot find an error in config. Everything seems fine |
Go in Administration -> Settings -> Repositories tab and enable Xitolite repositories. |
|
@n-rodriguez Thanks!! That saved my day!! |
|
After upgrading to 1.0 should the repos be of type Gitolite? I've enabled Xitolite, but the repository SCM is Gitolite. |
|
@n-rodriguez Thanks again for the quick help. Donated 50 €. Keep up the good work |
Thank you! |
Yep. It's normal : https://jbox-web.github.io/redmine_git_hosting/faq/#in-the-scm-list-gitolite-shows-up-as-xitolite |
|
@n-rodriguez Thanks! |
|
I'm running into another issue, if I'm trying to open an empty repository, Redmine just shows a 404 error message, not the instructions, how to clone this repository (as it was before) |
|
The following information is logged: The following is the error message I'm seeing in the browser: If you need anything else, just let me know |
|
@saz Can you please open an other issue? |
|
Good news regarding the last two posts: I fixed them both by deleting the repository in the database using SQL. After readding it in redmine everything is working now! Great work! |
|
Hi there, i got this issue when i do anything with redmine git hosting : from creating new repository, adding new key, edit repository , etc... Config test show all green. is there any i'm missing ? please let me know what is the problem with my implemetation. Thank you. |
|
+1 on leohartx comment.... also seeing same issue. redmine 3.0.3 with redmine_git_hosting 1.0.4, on amd64 FreeBSD 10.1 I am also all green on the config test |
|
After upgrade we get a bunch of repos that are Repository::Git, but the new one we create are Repository::Xitolite. We encountered a couple of inconsistencies in our schema (our database had a repo with multiple extras), so we had to restart the upgrade by hand a couple of time. It seems like in 0.7 patches would extend Repository::Git so they have the extra, is that still possible in 1.0 ? Or would we need to migrate by hand those repos ? |
No.
Normally this should have been done by the migration task. (http://redmine-git-hosting.io/how-to/migrate/#step-by-step-migration-from-0710-version-to-v10x). |
|
Hi, |
|
@n-rodriguez, we fix the error by opening the port in the firewall. Thank you very much for suggestion :) |
|
+1 It works like a charm. Thank you very much for this amazing plugin! |
|
Hello, unfortunately I run into problems when running 'bundle exec rake redmine_git_hosting:migrate_to_v1 RAILS_ENV=production' as it is throwing the following error: sorry for the ugly line breaks. |
|
@Jarvid : fixed in next release (1.1.2) |
|
+1
in steep 2, 3 and 4 i had problem with gem version like The migration script itself works excellent. Hooks should be installed by a migration script? |
Go in Hooks tab and click on Install hooks link. But before, check that SSH keys (public and private keys) exist and are readable by the user that runs Redmine. |
|
@n-rodriguez now everything is green :) Is there any way to add existing repositories to the project? |
|
Hi, I installed fresh (no migration) following the Get Started guide (http://redmine-git-hosting.io/get_started/) but had the same issue as @saz and this page was basically the only relevant result (maybe it's more of a grack or thin issue), so I hope people don't mind me posting my question here: You specified: redcarpet (~> 3.3.2) and redcarpet (~> 3.1.2) I switched redmine_git_hosting gem files to use redcarpet 3.3.2 and called bundle again, which outputs (among other things): Using gitlab-grack 2.0.0.pre from https://github.com/jbox-web/grack.git (at fix_rails4) Using redcarpet 3.3.3 Using thin 1.6.4 It launches successfully when I call: bundle exec rails server thin -b 192.168.1.2 -e production But stangely when launching with thin: thin start -C /etc/thin/redmine I get the following output: /usr/lib/ruby/vendor_ruby/bundler/source/git.rb:188:in `rescue in load_spec_files': https://github.com/jbox-web/grack.git (at fix_rails4) is not yet checked out. Run `bundle install` first. (Bundler::GitError) My thin config file is pretty basic and was working fine before installing the plugin: --- chdir: "/var/lib/redmine" environment: production address: 192.168.1.2 timeout: 30 log: "/var/lib/redmine/log/thin.log" pid: tmp/pids/thin.pid max_conns: 1024 max_persistent_conns: 100 require: [] wait: 30 threadpool_size: 20 user: redmine daemonize: true My fundamentals: Environment: Redmine version 3.1.1.stable Ruby version 2.1.5-p273 (2014-11-13) [arm-linux-gnueabi] Rails version 4.2.4 Environment production Database adapter Mysql2 SCM: Git 2.1.4 I also tried setting redmine_git_hosting gem files to redcarpet 3.3.3, and tried installing the grack gem from cloning manually, but no success. Confused! |
|
On further investigation I think it's a permissions issue, something like that gem is not visible when launching from init script, although the thin config should change to redmine user (maybe ENV parameter missing) |
The issue is that |
|
Thanks for your reply. Strangely that still doesn't work under root, i.e.: bundle exec thin start -C /etc/thin/redmine complains about grack not being checked out, where I'm pretty sure it used to run fine like that under root before. If I switch to redmine user then it runs with the exact same command & same dir, no complaints about grack not being checked out. I'm fine with my workaround in the init script (i.e. adding 'su redmine' there, which thin does anyway as it's in the config file), but I still don't get why. |
|
Just a quick comment from our migration (which now actually happened for real): We had quite a bit of trouble with invalid keys that were still in the database. The most frequent error was that there were whitespaces in the key data, and some users apparently pasted their private keys. In earlier versions, this didn't interrupt things, the keys just wouldn't work (I guess they were filtered out by gitolite). However now redmine-gitolite tries to pares these and errors out hard, such that the sync process interrupts. |
|
Gitolite itself can specify branch level access. In the end of your document you speak of repository level administration. Is this true? Is that not possible? |
|
The
I ran a def remove_inactive_key(key)
repo_keys = @gitolite_admin.ssh_keys[key['owner']]
repo_key = repo_keys.find_all{|k| k.location == key['location'] && k.owner == key['owner']}.firstThe Here is the output of my console:
gitolite_admin_dir = RedmineGitolite::Config.gitolite_admin_dir
gitolite_config_file = RedmineGitolite::ConfigRedmine.get_setting(:gitolite_config_file)
gitolite_debug = RedmineGitolite::ConfigRedmine.get_setting(:gitolite_log_level) == 'debug' ? true : false
gitolite_timeout = RedmineGitolite::ConfigRedmine.get_setting(:gitolite_timeout).to_i
gitolite_admin_ssh_script_path = RedmineGitolite::Config.gitolite_admin_ssh_script_path
gitolite_admin = Gitolite::GitoliteAdmin.new(@gitolite_admin_dir,
:config_file => @gitolite_config_file,
:debug => @gitolite_debug,
:timeout => @gitolite_timeout,
:env => {'GIT_SSH' => @gitolite_admin_ssh_script_path})
ssh_key = GitolitePublicKey.active.first
key = {}
key['title'] = ssh_key.identifier
key['key'] = ssh_key.key
key['owner'] = ssh_key.owner
key['location'] = ssh_key.location
#{"title"=>"redmine_eolepack_1393415509_779488", "key"=>"ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAxS82p1bPBB/xf6fjBiFsDMfAdcHCNlu2uotnryy35Ee4n8xQngKtpwDitRm9cX+qnFmUfxlXgZw83BVl14J4I0lzlZRsPyJqM6h4dwDhOxNI+ppUEb008Gh0WgWKUnmNrndTRlLgl7bP8mYSABthP7KmiU5GPdN5MbR0ieCvpzAszOg+zKUkhw9dvP3ZbTym5SwflxrkggWqngMbKmRmMK46PSBvW62Ms77njUWhe4iAkrqrwWRdfwg4oM7RsGY9udXvWYIpJBINZvh0NP732I38aTioSdbI/lxePrUPcwjUEg3ol1LvuYxcUieIAJ3lFrT+nGRT/XrwXAeB2CQxBQ== eole@athena", "owner"=>"redmine_eolepack_1393415509_779488", "location"=>nil}
repo_key = gitolite_admin.ssh_keys[key['owner']].first
#<Gitolite::SSHKey:0x00000008659e58 @type="ssh-rsa", @blob="AAAAB3NzaC1yc2EAAAABIwAAAQEAxS82p1bPBB/xf6fjBiFsDMfAdcHCNlu2uotnryy35Ee4n8xQngKtpwDitRm9cX+qnFmUfxlXgZw83BVl14J4I0lzlZRsPyJqM6h4dwDhOxNI+ppUEb008Gh0WgWKUnmNrndTRlLgl7bP8mYSABthP7KmiU5GPdN5MbR0ieCvpzAszOg+zKUkhw9dvP3ZbTym5SwflxrkggWqngMbKmRmMK46PSBvW62Ms77njUWhe4iAkrqrwWRdfwg4oM7RsGY9udXvWYIpJBINZvh0NP732I38aTioSdbI/lxePrUPcwjUEg3ol1LvuYxcUieIAJ3lFrT+nGRT/XrwXAeB2CQxBQ==", @email="eole@athena", @owner="redmine_eolepack_1393415509_779488", @location="">We see that I proposed the pull request #619 to fix this. |
It's possible : it's the "Protected Branches" feature, configurable in the repository settings. |
|
I managed to migrate from redmine 2.3.4 with plugin 0.6.3 to redmine 3.3.0 with plugin 1.2.1 (#488). Thanks. |
|
@baby-gnu Glad you finally did it :) and thanks for the step by step explanation (#488 (comment)) |
|
I am fighting to install this in a brand new server. |
|
very bad documentation and not really easy process for migration...
Make sure that there is no
EDIT:
UPDATE: some more issues I've encountered..
|
|
I am getting the below error by running this command [sudo bundle exec rake redmine:plugins:migrate RAILS_ENV=production NAME=redmine_git_hosting] == 20130807223227 MigrateParameters: migrating ================================ undefined method `true?' for Additionals:Module |
and others
Hi people!
I'd like to know how many of you are using this plugin and if the migration to the v1.x went fine for you.
Just add a +1 if it's the case. Feel free to add comments ;)
Thank you!
The text was updated successfully, but these errors were encountered: