Unknown query, check graphql schema / rest response structure.

May require #10 to query this access check.

This issue provides visibility into Renovate updates and their statuses. Learn more

Rate Limited

These updates are currently rate limited. Click on a checkbox below to force their creation now.

• Update dependency prettier to v2.4.1
• Update dependency @actions/core to v1.6.0
• Update EndBug/add-and-commit action to v7

• Check this box to trigger a request for Renovate to run again on this repository

• Request Endpoint (with authenticated token): either
  • GET /orgs/{org}/members
  • GET /orgs/{org}/members/{username}
• Request Endpoint (without authenticated token): either
  • GET /orgs/{org}/public_members
  • GET /orgs/{org}/public_members/{username}
• Path on payload (on list endpoints): ~.*.login
• Determine if member on check endpoints (~/**/{username}):
  204 if they are, 404 if they aren't.

Referring to a user's membership within an organization.

Future

Links back to #6 with enterprise site admin.

# predefined jobs / steps
- uses: sudojunior/access-check@main
  with:
    endpoint: https://git.example.com/api # defaulting to https://api.github.com

Carefully consider access scope, some modifiers may not work correctly if a user override is provided (i.e. issues, PRs).

May require authenticated token.

• Request Endpoint: either
  • GET /repos/{owner}/{repo}/collaborators - List (find by ~.*.login)
  • GET /repos/{owner}/{repo}/collaborators/{user}
    204 if they are, 404 if they aren't.

Specifically for private repositories?

• Return key: reader / observer / ??

Unknown directive or path to data.

• Return key: stargazer

Unknown query, check graphql schema / rest response structure.

While the rest endpoints are far easier to handle, graphql is far more precise and proves it's worth by showing the schema of the data before you handle the raw data (except for lists / arrays, but they are simple enough to work around).

Example query for the viewer's login, figuring out if nat is a Site Admin #6 and collaborator permissions for TinkerStorm/channel-backup; if they are a Site Admin (again) and if they are a Sponsor.

{
  viewer {
    login
  }
  user(login: "nat") {
    login
    isSiteAdmin
  }
  repository(owner: "TinkerStorm", name: "channel-backup") {
    owner {
      login
    }
    collaborators {
      edges {
        permission
        node {
          viewerIsSponsoring
          login
          isSiteAdmin
        }
      }
    }
  }
}

• Path on action: ${{ github.repository_owner }}

Referring to user scope only (possibility to determine if in user or org scope?).

Use insight data from ~/:owner/:repo/contributors?
Only first 500 are known.

Unknown at present, query is possible - but not sure if it can be done with the current structure (i.e. it can know if someone is part of a team, but it won't indicate which team(s) they are part of).

Requires #10

• Return key: ??

{
  viewer {
    isDeveloperProgramMember
  }
}

• Enterprise Endpoint?
• Role Accessors
  • site-admin
  • owner (repo)
  • member (org)
  • collaborator (member / org)
  • contributor
  • author (issue / pr)
  • none of the above
  • invalid user
  • campus-expert
  • sponsor (future)

Can be found on the viewer's side when checking any of the following:

{
  viewer {
    following {
      login
    }
  user(login: $owner) { # repository owner implied
    followers {
      login
    }
  }
}

Unknown query, check graphql schema / rest response structure.

If event is an issue, check github.event.issue.user?

If event is a pull_request, check github.event.pull_request.user?

Requires a condition to be run at the start of the action in order to halt itself before the query is run (otherwise resulting in a fatal code).

Unknown query, check graphql schema / rest response structure.

Unknown query, check graphql schema / rest response structure.

Consider that only the first 500 will be known.

It may require an interface rework on how ConditionBuilder handles key indexing.
~.toString() will be a key asset in making this work.

This idea comes from how the permission structure is handled in organizations in decending order:

• ADMIN
• MAINTAIN
• WRITE
• TRIAGE
• READ

Furthermore if the context is in an organization scope, Organization Member may in theory inherit from READ - but there are underlying settings that would cause a problem with this.

Requires #10

• Return key: sponsor

{
  viewer / user(login: $user) {
    isSponsoredBy(accountLogin: $sponsor) # $sponsor -> $user
    isSponsoringViewer # $user -> (viewer)
    viewerIsSponsoring # (viewer) -> $user
  }
}

An argument that would check for specific access groups instead of running on the full spectrum?

Requires #10, implies viewer is current target for query.

• Return key: bounty-hunter

{
  viewer {
    isBountyHunter
  }
}

Requires #10, implies viewer is the current target for query.

• Return key: campus-expert

{
  viewer {
    isCampusExpert
  }
}

Refers to the Campus Experts of GitHub's education program.

PS: Would this also include Campus Advisor

• Request Endpoint: GET /users/${{ github.actor }}
• Path on payload: ~.site_admin

Site Administrator

Referring to both GitHub Staff and Enterprise Instance Administrators)