gitpod icon indicating copy to clipboard operation
gitpod copied to clipboard

Allow maintainers with write access to an org repo to push changes to a contributor's branch directly

Open jtpio opened this issue 2 years ago • 10 comments

Is your feature request related to a problem? Please describe

Many open-source projects have adopted the following workflow for making contributions:

  • a central repository, usually under a GitHub organization
  • contributors fork the central repository
  • they make changes in their fork
  • then they submit a PR to the main repository

Which can also be illustrated as follows:

github-flow

Some of these contributors can be maintainers with write access to the central repo, some are casual contributors without such rights. These maintainers can usually push directly to the branch of the contributor repo, for example to make minor changes to a PR.

github-flow-2

However Gitpod does not seem to be allowing this at the moment.

Describe the behaviour you'd like

Just like the GitHub UI allows maintainer for pushing to the branch of the contributor:

image

It should also be possible to push to the branch of the contributor from a Gitpod instance from the command line with git push origin branch-name.

Here is a video summarizing the desired workflow. Attempting to do this on Gitpod gives a 403:

https://user-images.githubusercontent.com/591645/209089968-ea5fe7d8-d6f0-4026-8d67-21e0bab66127.mp4

Whereas it is possible to do this via the GitHub UI:

https://user-images.githubusercontent.com/591645/209090099-d5967675-1ea3-4d6c-982a-32a141411af3.mp4

Describe alternatives you've considered

I have been using the following workarounds for now:

  1. start Gitpod from a PR, make a small change, then copy the change from the Gitpod instance (for example a formatting / prettier pass). Then use the GitHub UI to edit the contributor's branch directly and paste the change.
  2. same as above, but open a PR targeting the fork of the contributor instead of pushing to the branch directly.
  3. clone the repo locally without using Gitpod. Make a change, commit and push to the contributor's branch directly. GitHub allows this from the CLI over SSH (and HTTPS?).
  4. open a new PR while keeping the commits from the original branch, just to be able to push new changes on top of it

Each of these have drawbacks:

  1. This is tedious, and doesn't scale if the change to apply is large
  2. This adds an additional round-trip and the other contributor first has to merge the PR. Sometimes they might not be notified about the PR on their fork unless they are pinged explicitly.
  3. This is a manual workflow that doesn't use Gitpod, which is long and tedious
  4. This breaks the normal flow of keeping the commits and the existing conversation in one place (previous comments and reviews are not moved to the new PR)

Additional context

This was also briefly discussed on Twitter a couple of months ago: https://twitter.com/jtpio/status/1555533757695856640

Thanks for the help!

jtpio avatar Dec 22 '22 08:12 jtpio

Just tried another scenario to double check the behavior, and it seems like there are also permission issues when trying to push to an org repo directly, even with full (admin) access to the repo.

Here a list of steps using https://github.com/jupyterlab/jupyterlab as an example (an organization repo on which I have admin access):

  1. Open Gitpod from https://github.com/jupyterlab/jupyterlab
  2. Wait for VS Code to load
  3. Create a new branch
  4. Make a change, then commit
  5. Try to push the change with git push origin my-branch

Trying to publish the branch on the origin (org repo) directly results in the following "Permission denied" error:

https://user-images.githubusercontent.com/591645/211581461-632d8a11-0b35-4bc8-9b42-b7d1f017face.mp4

However adding a new remote pointing to my fork and pushing to it works fine:

https://user-images.githubusercontent.com/591645/211581697-c497eaa1-6f3a-4191-818e-f237d6181b36.mp4

jtpio avatar Jan 10 '23 14:01 jtpio

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] avatar May 09 '23 06:05 stale[bot]

It would be nice to keep the issue open a bit longer as having support for this workflow would be super helpful to maintainers!

jtpio avatar May 14 '23 08:05 jtpio

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Sep 16 '23 22:09 stale[bot]

Commenting here after the stale bot :)

Still thinking it would be a great feature!

jtpio avatar Oct 04 '23 07:10 jtpio

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar May 22 '24 15:05 github-actions[bot]

Commenting again here as this would still be useful!

jtpio avatar May 22 '24 15:05 jtpio

We are not doing something special here, we just use the git token that we got from your OAuth. It could be that the JupyterLab org doesn't have granted access for Gitpod OAuth. Could you check this link and see what it says next to the jupyter org? You might request access, there.

svenefftinge avatar May 23 '24 07:05 svenefftinge

Oh that would explain why. I just granted access for another org, opened a PR created from the fork of a contributor, made some changes and pushed to the fork successfully.

After pushing the changes to the branch, the following notification showed up. Not sure it's relevant though since the changes were pushed successfully?

image

Thanks @svenefftinge!

jtpio avatar May 23 '24 14:05 jtpio

This can likely be closed then. Or this page in the docs could have a small mention of this use case too: https://www.gitpod.io/docs/configure/authentication/github#errors-with-private-repositories-on-github-orgs

jtpio avatar May 23 '24 15:05 jtpio