vermiculus / magithub

**DEPRECATED - please use Forge instead!** -- Magit-based interfaces to GitHub
GNU General Public License v3.0
579 stars 63 forks source link

No issues displayed for github enterprise repo #289

Closed t-jones closed 6 years ago

t-jones commented 6 years ago

Awesome extension to magit. I'm a github enterprise user, and when I fire up magit in a repo cloned from our enterprise github instance, no issues are pulled. I am able to see issues in the dashboard, so magithub and auth seem to be working fine. Did I miss something, or how can I chase this down? Thanks!

image

vermiculus commented 6 years ago

Are you able to see issues on GitHub.com repositories? If so, it might be an issue with a magithub.* git variable setting.

Otherwise check magit-status-sections-hook; if it doesn't mention any magithub symbols, check if you're missing something from the recommended config in the readme.

t-jones commented 6 years ago

I was able to see issues on github.com. I upgraded from melpa-stable to melpa and had the same issue; checking the git variables shows true for enabled and includeIssuesSection.

magit-status-sections-hook has the magithub symbols for inserting the pr and issues sections. I spent some time trying to see how magithub calls the github API for issues, but wasn't really able to get there. Happy to help with whatever would be useful to debug this.

vermiculus commented 6 years ago

Hm, then this is definitely an issue with the specific repository (or type of repository) itself. With default-directory in your repository, what does (magithub-repo) return? What about (ghubp-get-repos-owner-repo-issues (magithub-repo))?

t-jones commented 6 years ago

(magithub-repo) and (ghubp-get-repos-owner-repo-issues (magithub-repo)) look like they both return what they are supposed to, a lispy representation of the json responses! So that's encouraging. default-directory is what I was missing earlier in trying to test this, so thanks for that! What's next?

vermiculus commented 6 years ago

That's good news, but now comes the hard part. The entry point you're looking at is magithub-issue--insert-issue-section in magithub-issue.el; I suspect you're either not making it inside that when clause or something going wrong in magithub-issue-insert-sections.

t-jones commented 6 years ago

Think I found the issue for me; not sure if this is a defect or just something I missed. If you start at magithub-issue--insert-issue-section -> magithub-usable-p -> magithub-github-repository-p on line 411, there is some code that checks the current repo remote against the git config value for hub.host, and since I had not set up hub for this repo, magithub-github-repository-p was returning nil. Once I added the config value, everything worked just fine. Does magithub require hub? Thanks again for the pointers.

vermiculus commented 6 years ago

It does not, but at present I don't have a better place to look for whitelisted domains. Do you know of any other places that could be checked? @tarsius – do you have any plans for this? I'm wondering if we can parse auth-sources to find github-like authorizations, but I'm not sure that would be deterministic at all.

Closing this since it's a configuration issue, but clearly there are some tangible follow-ups.

vermiculus commented 6 years ago

(If you don't have plans, I can try something out downstream and we can see how it works.)

tarsius commented 6 years ago

I have no plans, just a vague feeling I will have to do something about this too eventually.

(If you don't have plans, I can try something out downstream and we can see how it works.)

An option should do the trick for now, right?

vermiculus commented 6 years ago

A defcustom? Yeah I can get something like that in place tonight.

vermiculus commented 6 years ago

@t-jones FYI, hub.host is now no longer respected; it's been replaced by magithub-github-hosts. See that variable for more details.

I have an inkling I'll want to move this back to a git variable or to a magit-owned variable eventually, but this should be good for now.

Personally, I think a git variable makes a bit more sense for all tools to share the same list… but we'll see.

howdoicomputer commented 5 years ago

@vermiculus I'm having this same problem right now. I'm on 20190101.2349 from Melpa and I don't get issues or PRs in my Magit status buffer. magithub-pull-browse works fine and magithub.status.includePullRequestsSection is enabled.

EDIT: Nevermind! Related to: https://github.com/syl20bnr/spacemacs/issues/10760

EDIT EDIT: Nevermind! The workaround in that Spacemacs issue wasn't applicable/didn't work.