Add git users only

[blackice2999]

Hi, i think it can be a good feature to add seperate git users with keys and option for r/w to repository so we can manage the repository fully over redmine. Currently i try to get access on a dev server to the repository it can be only done if i add them manually to gitolite and assign them to project or i need to add the key in my (or seperate) redmine user.

How do you think about them ?

regards Dennis

[kubitron]

I'm not sure what you are suggesting that is different. Are saying that you want to have repositories that are not managed by redmine but the keys are managed by redmine? Can you walk me through exactly what you would like to have happen?

[blackice2999]

Hi,

no the repository is managed by redmine but i mean that you can add separate keys to a repository for r/w access without to create them as redmine user. Sure i can add the keys to gitolite-admin and manage them manually but i think it will be nice if we had an interface in this plugin for this.

[kubitron]

Sorry for the delay. Do you think that there would need to be more than one key? Would you say that this is similar to #17?

[blackice2999]

Hi,

no problem. On first i would say thank your for your good work here! - Yes i think #17 tries to solve a similar problem but instead to provide only one key i think its better to add multiple keys with a name field to the project.

Simple example: We had a development server with multiple projects on it. Every project is a linux user now we want that a project on this server can clone / pull and sometimes push to the repositories. If you had now multiple projects you want to seperate them and sometimes you had multiple servers for one project (dev / live) and you want to add them to the repositories.

Currently Workflow: We need to create a redmine/chili user with password / email and so on. Add them the SSH Key, Add this user to a role (git only) and add this user to the project...

It could be simple if we can add simple keys with name to a project and simple right management (r / w)

Thanks!

Edit (added a fake example image):

[kubitron]

Ok. Would you add the keys elsewhere? What about a "deploy key" screen under the plugin settings screen? Then, the "project@devplace.xxx.com" would be in the key name field....? I am thinking of calling these deployment keys, in keeping with #17. I am going to forward those folks over here.

[blackice2999]

Hi, its not exacly the same... deploy keys at global settings ? why not directly in the project settings like the screen ? why deploy key restrict to read only ?

[kubitron]

@blackice2999, Not sure I understand. Wasn't implying read-only for repository (in fact, probably need these keys to be RW in most circumstances, but read-only might be occasionally useful).

[blackice2999]

hmm its hard i think we're talking past each other. I had read again #17 and i think you are right this could be the same. (my english leaves me at this point sorry)

[kubitron]

Not to worry. I believe that you are asking for something more than is being asked for in #17 (which is fine). I was just pointing out that your proposal satisfies the need for deployment key(s) mentioned in #17.

[gituser]

Very nice issue! I'd like to have this as well, currently doing it manually via git. Would be nice to have such nice feature.

[kubitron]

Hello. Well, I have a version of this working.

Anyone up for trying it?

[gituser]

@kubitron I'd love to test this, but unfortunately it doesn't work on 1.4

I get an error when I got to the repo settings.

I will try to check on 1.3 though now.

UPDATE: I get an error on 1.3 as well (it has to do something with database field):

Processing ProjectsController#settings (for x.x.x.x at 2012-08-16 21:59:13) [GET]
  Parameters: {"action"=>"settings", "id"=>"newlk", "controller"=>"projects"}
Rendering template within layouts/base
Rendering projects/settings
Creating bin directory: /var/www/redmine/vendor/plugins/redmine_git_hosting/bin/, Owner www-data
Setting up /var/www/redmine/vendor/plugins/redmine_git_hosting/bin/

ActionView::TemplateError (Mysql::Error: Table 'redmine.repository_post_receive_urls' doesn't exist: SHOW FIELDS FROM `repository_post_receive_urls`) on line #97 of vendor/plugins/redmine_git_hosting/app/views/projects/settings/_repository.html.erb:
94:                 </div>
95:             <% end %>
96: 
97:             <% if @repository.project.repository_post_receive_urls.any? %>
98:                 <div class="autoscroll">
99:                     <table class="list" style="margin: 1px 2px; width: 99%">
100:                        <thead>

    vendor/plugins/redmine_git_hosting/app/views/projects/settings/_repository.html.erb:97
    vendor/plugins/redmine_git_hosting/app/helpers/application_helper.rb:28:in `labelled_remote_form_for'
    vendor/plugins/redmine_git_hosting/app/views/projects/settings/_repository.html.erb:39
    app/views/common/_tabs.html.erb:24
    app/views/common/_tabs.html.erb:23:in `each'
    app/views/common/_tabs.html.erb:23
    app/helpers/application_helper.rb:222:in `render_tabs'
    app/views/projects/settings.html.erb:3
    unicorn (4.2.0) lib/unicorn/http_server.rb:530:in `process_client'
    unicorn (4.2.0) lib/unicorn/http_server.rb:604:in `worker_loop'
    unicorn (4.2.0) lib/unicorn/http_server.rb:487:in `spawn_missing_workers'
    unicorn (4.2.0) lib/unicorn/http_server.rb:137:in `start'
    unicorn (4.2.0) bin/unicorn_rails:209
    /var/lib/gems/1.8/bin/unicorn_rails:19:in `load'
    /var/lib/gems/1.8/bin/unicorn_rails:19

Rendering /var/www/redmine/public/500.html (500 Internal Server Error)

[gituser]

I created new project and tried to add a GIT repository to it, but after I select GIT it doesn't add any fields or buttons on that page :(

http://i.imgur.com/EHU1M.jpg

NOTE: I've updated to the latest head of master branch.

[kubitron]

On 8/16/2012 10:57 AM, gituser wrote:

@kubitron https://github.com/kubitron I'd love to test this, but unfortunately it doesn't work on 1.4

I get an error when I got to the repo settings.

I will try to check on 1.3 though now.

Hey -- are you talking about the Deployment users? Sorry, not posted quite yet...

--KUBI--

Professor John Kubiatowicz 673 Soda Hall Berkeley, CA 94720

[gituser]

Well, I tried this on redmine 1.4 first.

My 2nd message is a try on redmine 1.3. It didn't work too (even on new project).

Maybe I need to use specific branch for testing?

Thanks.

[kubitron]

Hold up a moment.... I haven't exported the code yet. Just seeing if I would have testers.

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

gituser notifications@github.com wrote:

Well, I tried this on redmine 1.4 first.

My 2nd message is a try on redmine 1.3. It didn't work too (even on new project).

Maybe I need to use specific branch for testing?

Thanks.

— Reply to this email directly or view it on GitHub.

[gituser]

@kubitron ok, let me know please when it's ready to test.

current master trunk is broken for 1.3 btw :(

[kubitron]

Really? Is the testing branch also broken? Neither should be. Please register a bug....

[kubitron]

Did you remember to run migrate_plugins?

[gituser]

Did you remember to run migrate_plugins?

ye, i forgot to do this.

seems to be working now, waiting for new feature functionality..

btw, there is a new function:

Post Receive URLs
Add Post Receive URL 

what does it mean? does it execute specified url after commit?

[kubitron]

@gituser, @blackice2999, @phindmarsh: OK. The testing branch now contains the deployment key implementation. It also has a new post-receive URL facility (which you discovered) that acts like the GitHub post-receive URLS (including the json information about what committed). There is are also improvements on the mirroring facilities.

I'd really like some feedback before I push to the master branch. For deployment credentials, go to the repository settings page and try to "add new deployment credential". This should be self-explanatory. Deployment credentials are owned by the user that entered them (such a user must be either an administrator or manager of a given project). They can be examined on the user's "my account" page.

[kubitron]

@gituser, @blackice2999, @phindmarsh: Don't forget to:

rake db:migrate_plugins RAILS_ENV=production

Otherwise, this will fail!

[gituser]

There is a bug with adding new users to deployment credentials.

If you add same key with different permissions - redmine will add first added key permissions.

i.e. if i add same key with r permissions and after that with rw - key will be used as 'r'

I think you need to check existing keys before adding them to deployment (or it could potentially affect other users keys?)

[kubitron]

Um. You shouldn't be able to add.key twice. Didn't you get a complaint when you tried to add again? (shouldnt be possible....)

[kubitron]

Can you explain what you did in more detail? You should not be able to ever add the same key to the same repository twice. (The key name should be greyed out).

How did you manage to add same key? When you say that you tried to add the key with RW permissions and it used R permissions, does this mean that you see the same key twice, both with "R" permissions? (Again, shouldn't be possible).

[gituser]

Hi!

The process is simple i go to project settings -> repository

I add the same key under 2 different names in the deployment credentials.

[kubitron]

Ah. That is an interesting problem that is true in general for all keys supported by this plugin. I suppose that I could enforce global uniqueness for keys. Why don't you add this as a separate issue, since it is a general bug that is not really related to the deployment key implementation.

[gituser]

UPDATE: nvm sorted this - mirroring works.

you need to init --bare repository to make it work.

what about just a copy of specific branch on the remote host?

let's say i have a devel branch and i want to update it via redmine (not bare just a working copy)? would be useful i think

[kubitron]

Mirroring will mirror everything by default (that is the "complete mirrororing" update mode). If you want something more specific, set mirror update mode to "force" or "fast forward" and then you can set the refspec to be exactly what you want... (you can update only a given branch, or even update one branch to another branch on the mirror, just like git push).

p.e. If you want to talk about more about mirroring (or register a bug), please set up another issue (I like to keep a trace of issues for other users). There is also a feature request (#47) which requested the enhanced mirroring...

[kubitron]

The testing branch now includes a patch to prevent the reuse of actual keys. It also validates the format of the key itself.

If you pulled up the testing branch in the last day, please clobber the last commit:

reset --hard HEAD^

Then, do a git pull again. Otherwise, just grab the testing branch.

[kubitron]

@blackice2999, @phindmarsh, any comment on this implementation of deployment keys?

[kubitron]

Ok. I'm going to close out this long-running feature request. Please let me know if there are any other problems or if the provided feature is not sufficient.

I have migrated everything to the master branch and incremented the version to 0.4.6x.

[phindmarsh]

Hi @kubitron, sorry I haven't replied. My installation of the plugin has unfortunately been overtaken by someone else (who I think has replaced redmine entirely) so I can't test it. Thanks for your work implementing this feature however, if I make another installation I'll be sure to let you know how it goes.

Thanks!

[kubitron]

Oh well. Sorry to hear that I lost a customer :-).

Good luck.

[blackice2999]

Hi kubitron,

works like expected, thank you so much for your work.

[kubitron]

Great!

I'll have things ported to Redmine 1.4 soon. Would you be interested in being a test subject?

[blackice2999]

Hi, sorry i use Chiliproject 3.x here

[gituser]

I'll have things ported to Redmine 1.4 soon. Would you be interested in being a test subject?

I'm up for it!

[kubitron]

Say, @blackice2999 Do you use Chiliproject 3.3? There was another use that was having problems, but I think that it was with Eric's original plugin.

@gituser, ok, I'm working my way through. Turns out that it requires some non-trivial changes to make it work with 1.4. I am wondering about that guy who ported directly to 2.0. He may or may not have figured out the right thing to do...

[blackice2999]

@kubitron thats right 3.3.0 - i have tested the deploy key feature with permissions r and rw+ and its run fine cant confirm any bigger problems here. Do you have some details about the problem ? so i can test it ?

[kubitron]

@blackice2999 -- no other details. He was having generic problems with the plugin not working at all. Unfortunately, he didn't register a bug here and he stopped responding to email...