Grapql viewer repositories gets only repositories where the user is collaborator

GitHub Ecosystem
#1

I am trying to run this query with my account by it is only returning repositories which I am contributor:

query ($first: Int, $after: String, $last: Int, $before: String, $sortDirection: OrderDirection!) {
  viewer {
    repositories(affiliations: [OWNER, ORGANIZATION_MEMBER, COLLABORATOR], first: $first, after: $after, last: $last, before: $before, orderBy: {field: NAME, direction: $sortDirection}, isFork: false) {
      totalCount
      nodes {
        name
        url
        updatedAt
        isFork
        primaryLanguage {
          name
        }
        defaultBranchRef {
          name
          target {
            ... on Commit {
              history(first: 1) {
                nodes {
                  authoredDate
                }
              }
            }
          }
        }
        owner {
          login
        }
        languages(first: 100) {
          edges {
            size
            node {
              name
            }
          }
        }
      }
      pageInfo {
        startCursor
        endCursor
        hasNextPage
        hasPreviousPage
      }
    }
  }
}

{
"sortDirection": "ASC",
"first": 100
}
2 Likes
#2

Hi @ajanoni,

Thank you for being here! Could you try to enable “Organization access” when authorizing the GraphQL API Explorer?

#3

I am using a personal access token with all grants enabled. 

#4

And when I use 

query ($first: Int, $after: String, $last: Int, $before: String, $sortDirection: OrderDirection!) {
organization(name: myorgname {
repositories

Then it returns all organization repositories. So I guess it is not an access grant issue.

#5

Hey @ajanoni, 

Thanks for the update! I think you might’ve stumbled on a bug here…I’ll report it to the API team, and will post an update here once I hear back.

Thanks again!

Andrea

#6

@ajanoni do you have any news on this one. I’m also in a need to fetch all the repos associated with my account but I’m only getting the public repos. Similar request works just fine with the v3 API.

2 Likes
#7

I can confirm that this is probably a bug because I do see private repos using graphql API with the same public token when I’m doing a search. For example:

{
  query: {
      search(query: "org:<my company name here>", type: REPOSITORY, first: 100) {
          repositoryCount
          edges {
              cursor,
              node {
                  ... on Repository {
                      name,
                    id,
                    nameWithOwner,
                    homepageUrl
                  }
              }
          }
      }
  }
}

shows public repos and private repos owned by \<my company name here\>. Still not perfect because it is not showing the forks but still.

#8

Still hitting this bug. 

Is the solution using the rest API for grabbing repos?

1 Like
#9

@vachi wrote:

Still hitting this bug. 

Is the solution using the rest API for grabbing repos?

Hi @vachi!

Hopefully, you found a workaround for this issue, but you may want to try combinations of the affiliations and ownerAffiliations arguments (possibly both!).  I ran into this issue in GitHub Enterprise Server, and these were the query arguments that worked for me:

query AllRepositories($cursor: String) {
  viewer {
    repositories(first:100, ownerAffiliations: [ORGANIZATION_MEMBER], affiliations: [ORGANIZATION_MEMBER], isFork: false, after: $cursor) {
      edges {
        node {
          name
          nameWithOwner
        }
      }
    }
  }
}

This started happening when ownerAffiliations was added to GitHub Enterprise Server 2.16 and to github.com.  When I contacted Enterprise support to debug the new query behavior, this was their response:

I believe the behaviour you’ve reported is as a result of a change that shipped in GitHub Enterprise 2.16 release series, where an ownerAffiliations parameter was added to the Repositories connection in our GraphQL API.

Before this change, the affiliations field was overloaded to mean both the affiliations that the viewer had with the specified repositories, as well as the affiliations between the user that the connection was operating on. This caused a host of issues in various places, and we opted to separate them out to allow for more flexibility.

In order to fix the above, you need to pass the relevant list of arguments to both connections, which should provide you all of the possible repositories. That is, for your query, pass both the ownerAffiliations: [ORGANIZATION_MEMBER] and affiliations: [ORGANIZATION_MEMBER] repository affiliation arguments.

  • Morgan
#10

This doesn’t work for me.

#11

Hi Andrea, has the team gotten back to you yet? This bug has existed for quite some time now and the only solution seems to be to go back to using the v3 API.

#12

Ah but it lead me to the correct solution: affiliations:[OWNER, ORGANIZATION_MEMBER, COLLABORATOR],&nbsp;ownerAffiliations:[OWNER, ORGANIZATION_MEMBER, COLLABORATOR], gets me the private repositories! Thank you!

#13

Never mind Andrea, I found the solution: need to set affiliations:[OWNER, ORGANIZATION_MEMBER, COLLABORATOR],&nbsp;ownerAffiliations:[OWNER, ORGANIZATION_MEMBER, COLLABORATOR]. Not sure why this is necessary for private organisations and not public organisations, but at least I can get all the repos I have access to now!

1 Like