How do I efficiently retrieve repos where I have contributed, but not owned by me?

[halhag]

Select Topic Area

Question

Body

I work in a large organization where we use GitHub. We would like to make an API call (REST or GraphQL) to GitHub to retrieve repos that are interesting to a specific logged in user - me for example. This could be repos that I have contributed to or repos that anyone in any of my teams have contributed to. Any one of these would be fine.

We do have possible workarounds:

1. We could loop the REST API https://api.github.com/repos/OWNER/REPO/contributors and check. We have close to 10 thousands repos though.
2. We have found some ways to loop the GraphQL API as well, but this also takes times, which means we end up having to query this once a day, save it to a database etc.

Surely there should be a way to do this in just one call.

We have tried the following with the GraphQL API:

• repositoryOwner: With login: "MyOrganization" we are only able to retrieve repos related to the organization and affiliations and ownerAffiliations looks like they follow the organization, not me as a logged in user. Note again that all the repos are owned by the organization, so that if I try login: "MyGitHubUser", I only get repos that I own privately.
• viewer: Here viewer.repositories retrieves only repos that the current viewer owns, not those they contribute to.
• repository: Only retrieves a single repo.
• search: We have tried query, but unsuccessfully (query documentation). The AI we have asked tries to use involves, but this does not retrieve contributors either.

Someone has suggested we look into OctoKit's GraphQL library, which is what we will try next.

We have looked at the REST API, but found only repo-by-repo possibilities.

Is this at all possible to do in one API call?

[victordami01]

Fetching User-Contributed Repositories in a Large Organization

Fetching all repositories a user has contributed to within a large organization in a single API call is quite challenging due to GitHub's current API limitations. However, here are some approaches that might help:

1. Using GraphQL API (Efficient Querying)

GitHub's GraphQL API provides a way to query user contributions without looping over repositories manually.

Using contributionsCollection to Fetch Contributed Repos

The following query retrieves repositories where a user has made commit contributions:

{
  user(login: "YourGitHubUsername") {
    contributionsCollection {
      commitContributionsByRepository(maxRepositories: 100) {
        repository {
          name
          owner {
            login
          }
        }
      }
    }
  }
}

🔹 To include pull request contributions, extend the query:

{
  user(login: "YourGitHubUsername") {
    contributionsCollection {
      pullRequestContributionsByRepository(maxRepositories: 100) {
        repository {
          name
          owner {
            login
          }
        }
      }
    }
  }
}

2. Using GitHub Search API (REST Alternative)

The Search API supports finding repositories where a user is a contributor:

GET https://api.github.com/search/repositories?q=user:YourGitHubUsername

3. Consider OctoKit for Optimization

Using OctoKit can streamline GraphQL requests with better pagination handling and performance.

Conclusion

There’s no single API call that directly fetches all contributed repositories across an organization, but the GraphQL contributionsCollection is the closest built-in solution. If you need a broader dataset, batching API calls and caching results daily may still be required.

Hope this helps! Let me know if you need further clarifications. 🚀

[halhag]

Thanks for the great reply! This looks very promising! We will test this! I hope it works :)

[victordami01]

Thanks for the great reply! This looks very promising! We will test this! I hope it works :)

Ok if it works, just mark this as an answer to your question

[halhag]

We have now tested and see that we get relevant repos for the last year with the first approach. We haven't tested the other suggestions, but this was plenty good enough for us and I marked it as an answer. Thanks again!