Allow configure for GH:E about alfred-github-workflow

[raine]

Great idea. 👍

[gharlan]

I would like to support this, but I'm not sure when I will have time for that.

Do you know what I have to do to support this? Is it enough to change the host?

[davelnewton]

Sorry; didn't see this dupe when I checked.

It isn't enough to change the host; I tried the naive approach. I don't remember what the issue was, something with API keys maybe? Sorry I can't be more helpful--I might jump into this one again.

[gharlan]

Please test this dev version: http://gh01.de/alfred/github/github-enterprise.alfredworkflow

It is totally untested because I do not have access to any enterprise server.

You have to use ghe instead of gh to access the enterprise api.
When you are using it the first time you can set the enterprise URL.

So please do this:

• Download and install the dev version
• gh > deactivate autoupdate (you can re-activate it after switching back to the stable release)
• ghe > url http://my_ghe_url
• ghe > login
• ghe <your query>
• Give me feedback (does it work or which step fails?)

[kylelundstedt]

@gharlan, thanks so much for trying to support GitHub Enterprise in your workflow. I tried testing your dev version, which failed at the "ghe > login" stage. It appears that we hadn't configured OAuth on our GitHub Enterprise instance.

Searching GitHub help, I found the following link:
https://help.github.com/enterprise/2.0/admin/guides/user-management/using-github-oauth/

It appears that GitHub is saying that "User authentication using GitHub OAuth is deprecated" for GitHub Enterprise. Does that seem correct? If so, is there an alternative way for your workflow to connect?

[gharlan]

Hmm, I'm not sure but I think it only affects the enterprise site login. "GitHub OAuth" means: authenticate with you github.com login to the enterprise server.

What I try to do is something different: Creating enterprise OAuth tokens for the enterprise api. Afaik this is not deprecated.
https://developer.github.com/enterprise/2.0/v3/enterprise/#authentication

Your Enterprise installation’s API endpoints accept the same authentication methods as the GitHub.com API. Specifically, you can authenticate yourself with OAuth tokens (which can be created using the Authorizations API) or basic authentication.

.

which failed at the "ghe > login" stage

It should open this page:
http://your_ghe_server/login/oauth/authorize?client_id=2d4f43826cb68e11c17c&scope=repo
Does the page exist? Error message?

[gharlan]

is there an alternative way for your workflow to connect?

Is there something similar to https://github.com/settings/tokens?
If yes: you could try to generate a new token and to save it to the the workflow this way:

ghe > login <token>

[gharlan]

Hmm, after more thought, I think the oauth login flow can not work because the oauth application (the alfred-github-workflow) is not registered in your enterprise instance (only github.com knows about my application).

But I think it should work the way I described in the previous post.

[e28eta]

Thanks so much for looking into this!

Yes, "ghe > login" opens the expected /login/oauth/authorize?... URL. Our enterprise instance (v2.2) shows a 404 page at that URL.

No, there's no /settings/tokens URL, that returns a 404 for me too. Nor is there a "Personal Access Tokens" section available through the UI.

I'll try to do some further investigation and research

---

Edit:
I found the "Personal Access Tokens" in /settings/applications

I started by looking at github.com/github/hub - it has the ability to create OAuth tokens on the enterprise server, but it seems to be doing it through the Non-Web Application Flow and using Basic Auth.

Manually generating an access token with the 'repo' scope works, but it doesn't look like it's being successfully used. I provide it through "ghe > login ", and see an Alfred notification that I'm successfully logged in to Github. However, any subsequent usage of "ghe" only shows the login, login , and "enterprise reset" options.

[e28eta]

Like you said in your latest post, /login/oauth/authorize fails with a 404 because the client_id is not recognized by our enterprise instance.

I'm able to register the workflow as my "own" application on our GH:E, but can't go any farther because there's no callback URL that'll be able to use my own client_secret to turn the temporary 'code' into an access_token.

Our instance is firewalled from the Internet (and probably most of our Intranet too), so I don't see the web flow working for us. However manually creating the token in the "Applications" section of settings is working great!

[e28eta]

I was running through some of the other features of this workflow, and discovered gist support was missing. #44 fixes them for me.

[gharlan]

@e28eta Thanks a lot for researching, debugging and fixing! :)
And nice to hear that it works (with your fixes).
The dev version should be updated: http://gh01.de/alfred/github/github-enterprise.alfredworkflow

I will remove the web login flow from the enterprise part. Instead I will add a link to the tokens page where you can generate the tokens.
So http://ghe_host/settings/applications would be correct? Can you generate tokens there?

[e28eta]

It was certainly made easier by all the work you put in, and the fact that there was a single flag to change for compatibility with Charles debugging proxy.

On our instance ghe_host/settings/applications combines the content from github.com/settings/tokens and github.com/settings/applications

You could also directly link to /settings/tokens/new - which appears to be the same page on GHE and GH: it's the form to fill out to create a new token. It does immediately prompt for a username/password to enter 'sudo' mode, so maybe that's less desirable than taking the user to the page with the "Generate new token" button that they have to push?

[gharlan]

single flag to change for compatibility with Charles debugging proxy

Yeah ;)

so maybe that's less desirable than taking the user to the page with the "Generate new token" button that they have to push?

I agree here. So I've added a link to /settings/applications.
Dev version is updated.
Could you please test it again? Please reset your ghe setup (ghe > enterprise reset) and start from scratch (ghe).

If everything is fine, I will release it soon.

[e28eta]

The basic functionality seems to be working great.

Issues and possible enhancements:

1. enterprise-reset does not clear the cache, I expected that it would delete urls from the enterprise URL. I don't think logout does either, and I think that could be a problem if I were switching user accounts. That's probably an uncommon use-case.
2. cmd-c and cmd-enter don't result in a working URL, for both gh and ghe. It's missing the host, and ghe's "URL" is prefixed with "e ". For example:
   • gh gharlan/alfred-github-workflow -> cmd-enter results in -> /gharlan/alfred-github-workflow
   • ghe user/repo wiki -> e /user/repo/wiki
3. cmd-y or shift doesn't seem to quicklook anything. I'm guessing this is related to 2
4. If I'm not on VPN (aka: cannot reach GH:E host) and the workflow needs to make a request (cache doesn't contain URL - or it's stale?), the workflow returns zero results, and Alfred defaults to the "Search Google, Amazon, Wikipedia" results instead. I don't know if there's a good solution to this, but the current experience is not great. I'm guessing the workflow behaves the same way if github.com is unreachable.

The second and third items seem to be regressions. I'm guessing the first and fourth are enhancement requests, and they could be moved to their own issue.

PS: I like the way you re-open Alfred with "ghe " after setting the enterprise url, that's a very nice touch.

PPS: Glad to help any way I can, and I definitely appreciate your time on a feature you don't use!

[gharlan]

Fixed 1., 2., and 3.

I don't think logout does either

It does. And I agree, cache has to be deleted on reset, too. Fixed it.

2. and 3) are alfred features. But I have to pass the full URL from 'search' to 'action'. Fixed it.

3. I will think about this later.

So, please test it again. :)

[e28eta]

The short answer is that the latest version seems to have broken some of the commands. I need to figure out all of the broken ones (and would like to figure out why they're broken - what they're trying to do that isn't working), but for example ghe my gists (works for gh) or ghe @user activity (broken for gh too) does nothing, but ghe my stars, or ghe @user contributions work for both gh and ghe.

[gharlan]

ghe @user activity (broken for gh too) does nothing

I can confirm this for gh (can not test ghe ;)) and I think I found the bug.
Dev version is updated.

[e28eta]

Still not working quite right. I figured out how to turn on Alfred debug logging, to see the item xml being generated.

my gists and @user gists generate URLs prepended with 'e ':
<item uid="..." arg="e https://github.foo.com/gist/SomeUser" autocomplete="e @SomeUser gists">
<item uid="..." arg="e https://github.foo.com/gist/e28eta" autocomplete="e my gists">

So does ghe > generate token:
<item uid="..." arg="e https://github.foo.com/settings/applications" autocomplete="e &gt; generate token">

Same with users who I'm following, with just ghe:
<item uid="..." arg="e http://github.foo.com/followed-user" autocomplete="e @followed-user "><icon>icons/user.png</icon><title>@followed-user </title><subtitle>User</subtitle></item>

And specific pull requests ghe SomeOrg/SomeRepo #1:
<item uid="..." arg="e http://github.foo.com/SomeOrg/SomeRepo/pull/1" autocomplete="e #1"><icon>icons/pull-request.png</icon><title>#1</title><subtitle>My Pull Request</subtitle></item>

As I try new functionality, like PRs and issues, it turns out the auto-complete on them looks broken too. For example, if I tab-complete the PR above, it converts into ghe #1, which is not good.

Same thing happens for specific branches ghe SomeOrg/SomeRepo @master:
<item uid="..." arg="https://github.foo.com/SomeOrg/SomeRepo/tree/master" autocomplete="e @master"><icon>icons/branch.png</icon><title>@master</title><subtitle>[commit number]</subtitle></item>

And specific blobs ghe SomeOrg/SomeRepo /README.md:
<item uid="..." arg="https://github.foo.com/SomeOrg/SomeRepo/blob/master/README.md" autocomplete="e README.md"><icon>icons/file.png</icon><title>README.md</title><subtitle>/README.md</subtitle></item>

I'm seeing the same behavior happen with regular gh commands:
gh gharlan/alfred-github-workflow #37 autocompletes to gh #37

I haven't checked if the autocomplete issue was introduced by the enterprise branch, but I believe the e https://... issue is causing the broken commands. I'm not sure I've caught all of them, especially because there are features of GH I haven't used yet.

---

Any idea how easy it is to set up a test-suite for workflows?

It seems like pre-populating the request cache could serve as a mock server, and then calling search.php and making assertions about the items XML that's returned could automate and future-proof the project. I almost got started on something like that, but thought I'd just do the manual testing and run the idea by you.

[kylelundstedt]

Works for me now, too! Thanks, @gharlan!

[gharlan]

@e28eta All the issues should be fixed now. Thanks again for testing. :)

Any idea how easy it is to set up a test-suite for workflows?

Good question. I'm not sure.
But I would really like it to have a test-suite, especially for the enterprise part.

[gharlan]

The version is released now. When there are bugs with enterprise support, please open new issues.
(Note: I still can not test it because I do not have access to any enterprise server..)

[cogell]

Thanks so much for this!

[gharlan]

So does it work?

[cogell]

@gharlan yea!

[davelnewton]

@cogell There can't be that many B Cedric Cogell's out there.

[cogell]

@davelnewton! The original reason I gave Alfred a try