Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

import from github/gitlab issues #27

Closed
r2evans opened this issue Apr 20, 2018 · 17 comments
Closed

import from github/gitlab issues #27

r2evans opened this issue Apr 20, 2018 · 17 comments
Assignees

Comments

@r2evans
Copy link

r2evans commented Apr 20, 2018

In concert with (but not necessarily wholly dependent on) #7, what are your thoughts to a form of connection using github webhooks and/or gitlab api?

For instance, imagine a webhook or helper script that syncs all current GH/GL issues with the current git-issues project, whether standalone or in the special branch suggested in my comment in #7.

Use-case: I travel often, and I'm either too cheap to buy on-plane internet access or it is unreliable. I'd like to be able to have a solid listing of my issues with comments and supporting artifacts. My current method is to go through each issue and print to a PDF, which is both cumbersome and prone to print-layout artifacts. (And the supporting artifacts are not necessarily attached.)

I see this potentially being done one or two ways:

  • manually with git issue import; the remote url could easily be saved/cached, similar to git remote; there would need to be internal differentiation between GH and GL.

    git issue import [email protected]:r2evans/myproj
    # optionally but not strictly necessary
    git push origin issues:issues
    
  • programmatically, where the GH/GL-hosted project has a trigger script (webhook or CI yml script) that automatically updates the issues branch when an issues is created/modified.

    git pull origin issues:issues
    

Thoughts?

@dspinellis
Copy link
Owner

This is a very good idea! It would also allow transition from GitHub issues to Git issues. I think the manual git issue import route (probably implemented in a separate helper script) is preferable to the push-based one, because the push-based one can be built upon the manual one.

@r2evans
Copy link
Author

r2evans commented Apr 20, 2018

Frankly, I think there would need to be an interface to push locally-created issues back to GH/GL, otherwise either (a) git issue needs to be read-only, or (b) the local issues would be a superset of those on GH/GL, not an ideal situation. (This suggests git issue export-like functionality.)

@dspinellis
Copy link
Owner

I fully agree. With "push" I meant a mechanism for pushing issues from GH/GL into a Git issues repo.

@dspinellis
Copy link
Owner

So GH/GL issues should appear like a git-issue (special) remote repo, which you can clone, pull, and push.

@r2evans
Copy link
Author

r2evans commented Apr 21, 2018

I might be able to work a PR for this as well as #9.

However, this patch will need to add either curl and jq (robust json parser) or switch to python (that has both network and json built in). Preference?

@dspinellis
Copy link
Owner

Great! I think the Unix shell is not an appropriate tool for writing the import/export code. A good approach would be an external Python helper program to do the GitHub API heavy lifting. Keeping the script compatible with Python 2.7 and avoiding external dependencies would be ideal.

@r2evans
Copy link
Author

r2evans commented Apr 21, 2018

I'm more proficient in py3, would that be okay, or is there specific reason to stay with 2?

@dspinellis
Copy link
Owner

Unfortunately, I see that many OS distributions either come with Python 2 being the default or only with Python 2. Therefore, to keep the spirit of hassle-free installation, providing Python 2 compatible code would be ideal. Could you perhaps try to write Python 3 code that's backward compatible with Python 2?

@dspinellis
Copy link
Owner

@r2evans ping: Do you have a draft time plan for the implementation? Do you need me to add any features to make the job easier? I see that we have assignee and tags, but we're missing projects and milestones.

@r2evans
Copy link
Author

r2evans commented Jun 5, 2018

Haven't had much time recently, still planning on working it. The first priority for me was to work on #9. For this one, I've been playing a little with python-gitlab, and since it supports API v4, we're good against GitLab's deprecation of v3. I have not looked at PyGithub much, and the documentation is extremely sparse, so it's tertiary for me.

@dspinellis
Copy link
Owner

Working on it.

@dspinellis
Copy link
Owner

dspinellis commented Aug 28, 2018

  • Import existing issues
  • Update issues
  • Import issue comments
  • Import milestone
  • Clever merge with conflict resolution
  • CI testing

dspinellis added a commit that referenced this issue Aug 28, 2018
dspinellis added a commit that referenced this issue Aug 29, 2018
dspinellis added a commit that referenced this issue Sep 1, 2018
dspinellis added a commit that referenced this issue Sep 1, 2018
dspinellis added a commit that referenced this issue Sep 1, 2018
@r2evans
Copy link
Author

r2evans commented Sep 6, 2018

Sorry I've been unresponsive since our last discussions, both for this and #9. I've been really jammed (with my paying job) and haven't had an opportunity to address this yet.

@dspinellis
Copy link
Owner

No problem! I enjoyed working on it.

@pmiddend
Copy link

I'd like to import issues from GitLab just once, to migrate to git issue. Is that possible (possibly using some branch) currently?

@dspinellis
Copy link
Owner

I'm not familiar with the GitLab API. If it's similar to the GitHub one, then it should be easy to adapt the GitHub import functionality to GitLab (e.g. by changing the API endpoints).

@dspinellis dspinellis self-assigned this Sep 22, 2018
@dspinellis
Copy link
Owner

Implemented by @vyrondrosos as part of GSoC 2019.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants