search

coala / meta

A repository for non-code activities, such as engagement initiatives, and other meta issues
6 stars 5 forks source link

Migrate coala-json from GitLab to GitHub #127

Open li-boxuan opened 5 years ago

li-boxuan commented 5 years ago

One of this year's GSoC projects is Result Reporter Tool (see https://summerofcode.withgoogle.com/projects/#6527640138153984 and http://projects.coala.io/#/projects?project=result_reporter_tool&lang=en).

Currently, we have a repo called 'coala-json' on GitLab, https://gitlab.com/coala/coala-json, which could be used as a bed for the Result Reporter Tool project. However, as this project involves some CI integration, e.g. CircleCI, it is better to have the repository resided on GitHub (GitHub supports CircleCI while GitLab not). The student @chay2199 is more familiar with GitHub as well.

For the sake of this year's GSoC project, I propose:

  1. Migrate https://gitlab.com/coala/coala-json from GitLab to GitHub. We can keep the GitLab repository for now, so that the student might want to switch between GitHub and GitLab when necessary.
  2. Rename the repository to coala-reporter, or similar. The original name coala-json might be confused with coala --json mode, and the scope of this project seems to be sometimes out of the scope of 'json'.

ping @jayvdb

jayvdb commented 5 years ago

Renaming is a good idea. Not sure if 'reporter' is idea as it suggests a CLI doing something, when it should also be usable as a library. Also not sure 'coala' should be in the name, as the scope extends beyond coala a bit. Anyways, the name doesnt matter until the library is usable and needs to be published on PyPI, at which time the name should be finalised.

One main reason to keep the project on GitLab, and sync to GitHub, is the permissions system on GitLab is much better. The GitLab projects last year had more freedom , being owners of their own repo , ping @virresh and @MacBox7 .

Development of integration of GitHub with CI could be achieved on personal GitHub clones (@username/foo) and then also in production with GitHub @coala/foo sync connected to the various CI, so commits on GitLab repo are mirrored to GitHub which triggers CI and it all 'should work'. However, that wont be ideal if the project needs to use GitHub PRs on the org repos.

Anyways, as for doing this, I have only set up mirroring on GitLab, which has configuration to pull or push from any git repo, so it can do the sync in either direction. There is also GitLab export functionality, and GitHub import functionality, so that might be a better way of doing it, as that should also transfer the issues, MRs->PRs, etc..?

li-boxuan commented 5 years ago

There is also GitLab export functionality, and GitHub import functionality, so that might be a better way of doing it, as that should also transfer the issues, MRs->PRs, etc..?

https://github.com/ubc/github2gitlab is a script which also migrates PRs to MRs, but I did not try. But I guess mirroring PRs/MRs is not a concern atm.

jayvdb commented 5 years ago

I think this project should stay on GitLab for at least the first little while, where maintainers are able to merge, which includes mentors on this project. Due to the GitHub permission structure, and the state of our automation systems, only owners can do merges, and owners are harder to convince that a change is ready to be merged :P, and owners are harder to access reliably.

AppVeyor and GitLab CI can be done without GitHub.

Demo GitHub projects can be used to test the new tool with Circle CI, and the new Azure Pipelines if it also has similar functionality.

li-boxuan commented 5 years ago

I think this project should stay on GitLab for at least the first little while, where maintainers are able to merge, which includes mentors on this project.

Sure. Can you give me permission to that repository (https://gitlab.com/coala/coala-json)? Thanks.