we’d like to use CircleCI to build some open-source repositories under the soundcloud org, but we do not want to use it for private repositories yet.
The CircleCI access request in Github says “Granting access will give this application the ability to request access to private data in the soundcloud organization”. What data will CircleCI be able to access exactly? Will it be able to access private repositories (and how?), or will it only be able to ask for access to them?
Google turned up a similar question here, but it was closed without a response.
I read the page you linked, and it’s pretty clear for personal repos – I’m able to choose whether CircleCI can access private or only public repos. However, we’re confused about what level of access is granted if we enable access for a Github org; there doesn’t seem to be the same distinction?
The wording on the access request approval page (that I quoted in the OP) says that CircleCI will be able to “request access to private data”, but we’re not clear what “private data” means in this context (private repos? read and/or write access? organization membership?), and whether there will be another approval step to grant actual access to this data.
Under the covers, a GitHub org and a GitHub user’s account are almost the same when it comes to API calls, in the sense that CircleCI accesses them.
The Private access we need boils down to how GitHub Scopes work. We need “private access” to be able to see what repos you have, who the members are, and to add deploy keys and hooks.
thanks, I think this is where we’re getting nervous, too. Do I understand correctly: for personal repos, I can chose whether to grant repo or public_repo scopes, but org access always requires the repo scope? I think we’d like to request public_repo scope for the soundcloud org. Is there a way to do that?
It should be exactly the same. Signing up with public-only will only allow us to see any public org project you have access to.
To clarify, orgs aren’t users, so you are always signing up to CircleCI as yourself. The scopes then control what GitHub will send us regarding what you have access to, but personally and as an org member.
ah, so maybe the issue is that the person who initially made the org access request (it’s been sitting around a long time) was signed in to CircleCi with repo scope, which made the org access request also have that scope. Maybe we can try to revoke that request, and then make a new one while signed in with public_repo scope?
To close the loop here: we got in touch with Github support; they say it is not possible to grant access only to public repos given the current way that CircleCI integrates with Github, and suggest that integrating as a Github App would be a better fit for CircleCI:
… [OAuth org access] policy is not related to any particular set of scopes – it’s related to the application regardless of scopes. In other words, you either allow or disallow an application. If you allow it, then you allow it for any scopes it might have obtained from users who authorized it.
The best solution here would be for CircleCI to switch their integration from an OAuth App (based on scopes) to a GitHub App (based on more finely granular permissions. With GitHub Apps, you would be able to grant the application access only to a single repository, as an owner of the organization.
OAuth Apps aren’t really suited for that kind of access – there’s no per-repository access and as an organization owner you can’t set policies based on scopes.
