GitLab support

[knocte]

User Story

as a repo maintainer, I want to be able to use GitCoin if I have a repository in GitLab instead of Github

as a user, I want to be able to fund issues in GitLab repositories, not only Github ones

Why Is this Needed

Summary: It's important that Gitcoin stays agnostic to the git platform being used (otherwise it should be called githubcoin! :P ). Especially given that GitLab is opensource (as opposed to Github) and aligns better with Gitcoin's own opensource nature too.

Also, given that GitLab can host private repositories for free (as opposed to Github, which has this as a commercial service), this feature is more likely to be useful when #3449 is implemented.

Description

Type: Feature

[gwpl]

Many users prefer GitLab to GitCoin for variety reasons.

To me it's also question of the spirit of space : decentralisation.
Providing support to one then one platform is good for many reasons.

Please do provide:

• support for GitLab projects or separate version of gitcoin for gitlab?

Please consider providing until it's implemented:

• documentation how to use GitCoin for GitLab users, ok instructions how to brindge via GitHub (e.g. sync to GitHub, make bounty, accept pull request, and sync back to GitHub, or other operations, preserving authors signed commits (if possible and if author signs commit), etc.)

Related reddit thread: https://www.reddit.com/r/gitcoincommunity/comments/attpyx/how_to_use_gitlab_projects_with_gitcoin/

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

This issue now has a funding of 0.28 ETH (41.21 USD @ $147.18/ETH) attached to it.

• If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
• Want to chip in? Add your own contribution here.
• Questions? Checkout Gitcoin Help or the Gitcoin Slack
• $59,065.49 more funded OSS Work available on the Gitcoin Issue Explorer

[knocte]

I just put about 40USD as a bounty for this. @gwpl you're welcome to vote with your wallet to this issue now, let's make this happen! (you can add extra funds to an existing bounty, last time I looked gitcoin already supported this crowdfunding-mode model)

[iamonuwa]

This is nice, but what do you think of adding login with GitLab as well?

[knocte]

This is nice, but what do you think of adding login with GitLab as well?

Fine by me of course, but maybe can be considered a separate issue (that you're welcome to file separately). Bounties should stay as small as possible in scope so that a bounty-hunter can have a clear goal.

[xiaods]

please review the work and list todo-list to clean the workround.

[knocte]

please review the work and list todo-list to clean the workround.

Sorry, what?

[xiaods]

@knocte i suggest list a checklist to help what need implement. e.g.

[knocte]

Sorry but I only see 1 item in that checklist:

• Make gitcoin support gitlab.

I don't see how this can be more simple really :)

I'm guessing, though, that a developer might understand this better if what I explain here is, instead of a checklist that needs to be done, an "acceptance test" that I would perform to check if the work covers the full picture. So, I would do this to test this work:

1. Fund an issue that is in gitlab.com instead of github.com
   Expected result: issue should get a gitcoin comment with the info about the bounty.
2. Make a worker apply to the issue.
   Expected result: issue should get a gitcoin comment explaining that the work is in progress.
3. Make a worker submit a pull request in gitlab.com that references the gitlab issue. Then worker should click on "submit work" in gitcoin.
   Expected result: funds contributor should get an email notification that he needs to review the work.
4. Approve work submission.
   Expected result: bounty should be payed out to the worker, and gitcoin should send a message to the github issue about this.

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

Work has been started.

These users each claimed they can complete the work by 11 months, 3 weeks from now.
Please review their action plans below:

1) svipal has started work.

Hello ! I've been looking at this.

From what I've gathered here's the action plan for the first part (accepting the issues).

• make gitlab equivalent functions to the already existing github ones in app/git/utils.py
  concerned functions (only those that deal with adding issues, not the github auth ones):
  github_connect
  get_gh_issue_details
  get_gh_issue_state
  *Means there is a need for importing https://salsa.debian.org/debian/python-pygitlab
• properly route gitlab issues to said equivalent gitlab functions in app/dashboard/helpers.py:issue_details
• allow gitlab urls in app/assets/v2/js/shared.js:retrieveIssueDetails
• change app/dashboard/templates/bounty/new.html to reflect the new dual github/gitlab policy
  • change "edit on github" and "sync with github"
  • remove the github logo in the style.

Questions, observations :
- in the issue_details function in app/dashboard/helpers.pythere is a TODO :
* Modify the view to only use the Github API (remove BeautifulSoup).
* Simplify the view logic.
What should be done ? Just update the todo to include the Gitlab API ?
- I don't know yet how similar these two APIs are. I feel like a lot of the site was made with only Github in mind.
Links for comparison
https://python-gitlab.readthedocs.io/en/stable/api-usage.html
https://pygithub.readthedocs.io/en/latest/
- there's a need to separate the github auth stuff from the github issue stuff.
Could anyone familiar with that side of the project tell me what's up with the gazillion GITHUB_... variables in app/app/settings.py ?
there's a #TODO next to most of them.

 In particular I'm not sure about the following things, should we :
- add social_core.backends.gitlab.GitlabOAuth2' to the AUTHENTIFICATION_BACKENDS in app/app/settings.py 
- add gitlab specific settings to app/app/settings.py
- add gitlab specific env variables to app/local.env
	At first glance, seems like we would only need GITLAB_API_TOKEN for the issues. 
	But there's also a #TODO to it in settings, maybe  it's planned future functionality.

Learn more on the Gitcoin Issue Details page.

[knocte]

@svipal: if you try to migrate every github occurrence that you find in the codebase, you might never finish, I mean, it could be a job that takes too long because there may be a lot of github-related features. What I proposed in #issuecomment-466855718 though, is that you take the simplest functionality, and make that work. Change your OS' hosts file to make the domain github.com point to garbage (e.g. 0.0.0.0) and try the acceptance test until you find the first problem, then fix the code to use gitlab instead and restart testing the acceptance test. Repeat this until the whole acceptance test works.

[svipal]

I'm not trying to blindly migrate every github occurence, don't worry.
That's what I meant by "there's a need to separate the github auth stuff from the github issue stuff".
I only want to deal with github issues for now, and not touch the auth unless it's needed. (it's needed at one point during the github issue validation process, that's why I was talking about oauth and the API token)
I agree with the idea of taking the simplest functionality and making it work - that's why I said the first step was to accept gitlab issues.

[svipal]

Been doing some more digging.

• There's also web/app/dashboard/models.py where every issue is assumed to be a github one , need to weave gitlab into that.
• Need to change create_new_bounty function in app/dashboard/helpers.py:issue_details so that it calls the gitlab eq to get_gh_issue_details if the issue is a gitlab one.

I'm planning on short term to just make it work following the above acceptance test; then ideally what should be done is do a repo agnostic layer so that it's easy to add others on top of it such as bitbucket.