Fetch or push, publish Branch does not work

[freemimp]

Describe the bug

When I press "Publish branch" button anywhere, as in Repository -> push, Ctrl P, or just button at the top, it does nothing.... Same for Fetch or any other action except create branch or commit.
it pushes or fetches, like 5-10 minutes later.....

Version & OS

Ubuntu 20.04, And I am using Version 2.5.0-linux2

Steps to reproduce the behavior

1. Open Github Desktop.
2. Try publish branch or Fetch,
3. nothing happens and there is no visual response apart from ui selection - back ground changes

Expected behavior

gives you clear UI response and fetches, or publishes branch

Actual behavior

Nothing happens of the above, so I need to do it manually. - terminal or in build vcs, or wait for 5-10 minutes....

Screenshots

N/A

Logs

Attach your logs by opening the Help menu and selecting Show Logs..., if applicable.

Additional context

2020-05-27.desktop.production.log

[shiftkey]

@freemimp it looks like there's a Git-specific issue in the logs that's impacting anything network-related:

2020-05-27T17:16:37.747Z - info: [ui] proxy url not resolved, protocol not supported

Do you have a proxy configured via environment variables or something similar?

[shiftkey]

I can also see this error when we try to query for the repository:

2020-05-27T10:42:29.169Z - warn: [ui] fetchRepository: 'costa-coffee/costa-coffee-app-android' returned a 404

If this is a private repository, I think you're also encountering #281

[freemimp]

Hi @shiftkey I don't use any proxy, but this is indeed private repo with 2FA enabled. What is the solution? I wish I could help, but my electron/ JavaScript skills are close to 0...

[shiftkey]

@freemimp the solution to this isn't an easy fix, and I wrote up the options a while ago:

What you suggest to do then? On windows and Mac is working properly.

This is because I maintain the unofficial releases for Linux, and it doesn't contain the OAuth details required to behave the same. This is being discussed in desktop#1525 (please upvote if you care) but #72 is tracking this known limitation.

As I want to keep this separate until the team is interested in official support, the only other option here would be for me to embed a new set of OAuth details that would belong to a distinct entity to avoid confusion with the main "GitHub Desktop" product. That's branding work I'm not able to take on currently, and I want to focus currently on ensuring the app installs and works on various distros.

Introducing a new brand also won't address the solution completely because organization administrators need to approve access to this new application.

[freemimp]

Hi @shiftkey , I don't use OAuth, this is private repo in Organization that I work for using ssh and private token, I can login on Github Desktop and even enter 2FA code in browser, so not sure what is the problem, it mentions something about repo not being in the database.
I had a look at logs today, it seems to find token and eventually it pushes or fetches, but it is extremely slow. I tried with my own private repo and it works flawlessly, so issue is definitely with private repos that are belonging to organization.
Thanks

[shiftkey]

@freemimp if the remote is an SSH remote, GitHub Desktop will fall back to using it. But if you're working with a HTTP remote the Git operations inside Desktop will use a token obtained using OAuth, instead of using your credential helper. We use the same token for interacting with the GitHub API to get details about the repository (which helps to show the list of PRs, issues and other details).

I need to give the log a closer read to understand what might be happening - hopefully this weekend.

I tried with my own private repo and it works flawlessly, so issue is definitely with private repos that are belonging to organization.

Cool, that also fits with how I believe this should work.

[vicpermir]

We are having the exact same problems, we want to migrate all our machines to work with Linux but this is being a major headache because nobody can see organizational repos, at all.

As a dirty workaround you can disable App restrictions if you go to Your Organization > Settings > Third-party access and click on the red button "Remove restrictions". I don't know what kind of security issues this could introduce.

Thanks for the work you do on this @shiftkey :)

[shiftkey]

Looking at the logs again I think this is due to organization restrictions on the repository:

2020-05-27T17:43:06.378Z - info: [ui] [fetchPushControl] unable to check if branch is potentially pushable
Error: Not Found
    at Object.t.parsedResponse (/home/freemimp/webpack:/app/src/lib/http.ts:175:4)
    at x.fetchPushControl (/home/freemimp/webpack:/app/src/lib/api.ts:844:14)
    at Qe.refreshBranchProtectionState (/home/freemimp/webpack:/app/src/lib/stores/app-store.ts:908:29)
    at /home/freemimp/webpack:/app/src/lib/stores/app-store.ts:4157:9
    at Qe.withPushPullFetch (/home/freemimp/webpack:/app/src/lib/stores/app-store.ts:3752:7)
    at Qe.performFetch (/home/freemimp/webpack:/app/src/lib/stores/app-store.ts:4119:5)

I think this is covered by #281 but perhaps we need to improve the messaging a bit before closing this out, as it seems this is being swallowed rather than displayed to the user...

[borodinalive]

I have almost same bug. To manage it I should make blur from github window and make it active again. Any network activities solves this way
Kubuntu 20.10
KDE Plasma 5.19.5

[shiftkey]

@borodinalive can you please re-test the latest release - 2.8.1-linux3? I think we have a fix for the Git operations that seems to help other users...

[borodinalive]

@borodinalive can you please re-test the latest release - 2.8.1-linux3? I think we have a fix for the Git operations that seems to help other users...

no... all the same

[shiftkey]

At the moment I'm going to have to close this out as a newer release of Electron meant this problem re-appeared in a different form #690 and I think we can drop the custom fix that we used (my working theory is that Node changes with how process interop worked across major versions).

I'd love a fresh bug report if someone is still seeing this on their end.