Help: Run gitStream for forked pull requests

[jfairley]

I've set up gitStream within my private org using a cm repo following https://docs.gitstream.cm/github-installation/.

In our org, our members fork first and submit pull requests from their fork.

I have seen the github actions run in cm in response to opened pull requests 🎉 but the job cannot see my forked repo.

Can you guide me to what I need to change to grant gitStream the necessary permission? Do I need to go into the individual forks, or is there something I can set on the org or on the individual upstream repos?

Thanks!

[jfairley]

To be clear, the fork doesn't hold the pull request, only the source branch.

ex: <org>:main <- jfairley:my-new-changes

[jfairley]

[vim-zz]

@jfairley to help understanding the reason for your issue, did you install gitStream on the org of the forked repo (not jfairley)? i.e., did you install gitStream app in your private org, and added the cm repo to it (not under github.com/jfairley)?

Another question, does it fail on all PRs or do you see successful gitStream results on other PRs?

[jfairley]

@vim-zz Thanks for the questions!

Correct, I installed gitStream in the org repo, which owns the upstream of my forked repo.

So

• <Company> has the gitStream app installed, where it has access to all repositories
• <Company> owns code repos, which I and my co-workers fork and submit PRs from.
• <Company>/cm has the gitStream action and configs. Everything I have so far is copied from the docs site.

It does fail on everyone's PRs.

📸 screenshot org app permissions

📸 screenshot cm repo layout

As a matter of curiosity, today I ALSO installed gitStream at github.com/jfairley, but that did not resolve the permissions issue.

[jfairley]

I should've verified this sooner...

I just pushed my branch to the <Company> repo and created PR branch-to-branch within the same repo. I have had success there, thereby confirming that I have a permissions issue uniquely with PRs from forks, but otherwise, the system seems to work.

📸 gitStream activity on an in-repo PR

Unfortunately 99.9% of our PRs come from forks.

[vim-zz]

@jfairley so far we could not reproduce your issue. Would you be open to a brief call with us to discuss it further? You can schedule a meeting directly to my calendar

[jfairley]

@jfairley so far we could not reproduce your issue. Would you be open to a brief call with us to discuss it further?

Thanks @vim-zz. I set up a time for tomorrow.

[vim-zz]

@jfairley probably a timezone issue, but we missed you. We did dig further on our own and we understand the problem, its lack of access permissions to the forked repo source code, from the GitHub action that runs on the original repo (https://github.com/actions/checkout/issues/551). We have been able to reproduce your issue and tried few different settings but could not get it working. I will update when we I have news.

[jfairley]

Oh, I thought I chose today at noon, but I've been searching my email and wonder why it wasn't on my calendar. Must've been a timezone issue. I'm sorry!

Edit.... omg I chose midnight. What TZ are y'all? I'm in Colorado. So so sorry.

[vim-zz]

No worries! we are GMT+3

[jfairley]

We did dig further on our own and we understand the problem, its lack of access permissions to the forked repo source code, from the GitHub action that runs on the original repo (actions/checkout#551). We have been able to reproduce your issue and tried few different settings but could not get it working. I will update when we I have news.

I thought that might be the issue. If it's possible to get us there even through manual configuration, I'm happy to do it. In other words, potentially granting read permission to a gitstream bot user. We had to do something like that for https://github.com/renovatebot/renovate, though that is a little different since there bot is for PR approval and automerge.

Long term, we've started discussing internally moving team PR sources to the upstream. It's a big process shift and comes with adding automation for stale branch management, but it seems like your DORA metrics will work better with upstream PR sources, so we're looking into it.