updated fork feature to use gitlab-shell for v5 of gitlab

[amacarthur]

Replaces pull request #3382

Dependent upon gitlab-shell pull request: gitlabhq/gitlab-shell#45

This will provide a button on the project page which will create a fork of a project into their own namespace. The fork from/to relationship is recorded in anticipation of gitlab handling cross-repo pull requests.

[coveralls]

Coverage decreased (-11.91%) when pulling ae33fdf on amacarthur:fork-pull-request into 63b78a3 on gitlabhq:master.

View Details

[elestedt]

Too bad that the build faild :(

[amacarthur]

Is there anyway to retry the build? The failure is in an area entirely unrelated to my changeset, and from what I've seen, capybara is prone to intermittent falure.

 1) On a merge request diff with muliple note forms posting a note should be added as discussion

Failure/Error: find('a[data-line-code="342e16cbbd482ac2047dc679b2749d248cc1428f_18_17"]').click

Capybara::Ambiguous:

Ambiguous match, found 2 elements matching css "a[data-line-code=\"342e16cbbd482ac2047dc679b2749d248cc1428f_18_17\"]"

# ./spec/features/notes_on_merge_requests_spec.rb:128:in `block (3 levels) in <top (required)>'

[fbender]

So if I understand correctly, you cannot merge (PR/MR) forks back into any branch of the original repo. However, I think it is vital for this feature to actually allow to send your work in the forked repo back to the original one. Is this being worked on somewhere else?

[amacarthur]

@fbender Yes - this is actively being worked on.

[dzaporozhets]

allowing fork project for guest role is bad. Guest role does not have access to source code

[dzaporozhets]

@amacarthur its almost in upstream. Few notes left :)

[amacarthur]

Excellent! Thanks @randx

[amacarthur]

I hope to update this pull request today. I have encountered a bug that I need to address before this should be merged.

[coveralls]

Coverage decreased (-12.81%) when pulling ec63804 on amacarthur:fork-pull-request into 63b78a3 on gitlabhq:master.

[amacarthur]

Travis build failed only when attempting to run with Ruby 2.0.0. The failure is due to a known Ruby 2.0.0 issue. See rails/rails#9417 (comment)

[dzaporozhets]

@amacarthur thank you. Lets merge it :)

[elestedt]

Wonderful. Thanks @amacarthur for all your work on this. And for not giving up 👍

[dzaporozhets]

@amacarthur since

private method `initialize_dup' called for #<Project

for ruby 2.0 we should find a better solution.
We already use 3.2.13 and I'm not sure its rails related (even if true they are not going to provide a release in closest month I guess) so we should fix it.

[dzaporozhets]

@amacarthur Can you please make it work with ruby 2.0 today or should I fix it?

[PEM-FR]

This feature is an awesome addition to gitlab! 👍

[amacarthur]

@randx Looking into it now.

[amacarthur]

Thanks @PEM-FR and @elestedt .

Thanks especially to @randx for being open-minded and accepting a change he was initially unsure of.
GitLab rocks!

[amacarthur]

Fix for failure using ruby 2.0:

#3829

[dzaporozhets]

@amacarthur thank you for quick fix :) Also thank you again for good contribution!

[junxy]

Suggest fork feature add configurable options, and default project features settings, Just like:
gitlab.yml

    ## Default project features settings
    default_projects_features:
      issues: true
      merge_requests: true
      wiki: true
      wall: false
      snippets: false
      fork: false ##here

Thanks!