Travis account for R3N

I thought about setting up Travis for the testing of the MySQL branch of R3N/ren-c repository. So I went to Travis-CI.com to sign up my Github account. When I got to the page to give consent to Github to allow Travis access I found out:

  1. Travis wanted read AND write access to all my repo's, including my PRIVATE repo's.
  2. All my organisations could be chosen to GRANT access also, EXCEPT for R3N

At point 1. I do not see why I should give Travis access to ALL my repo's especially the PRIVATE ones. I do not want Travis to have this power, it only needs access to those repo's I want tested by it.
At point 2. I created the R3N account and I am owner. Why can't I select this, the only one that makes sense? Is it because it has no own repo's in it, just clones?

Are there other ways to test extensions that are acceptable for the project, so the branch could be integrated some day?

It should have given you a choice. You can select which repos to give access to for any GitHub app, under Settings -> Integrations:


I think you are probably adding from travis-ci.COM ("pro" version), not travis-ci.ORG (open source, free)

The free form of Travis cannot be used with private repositories, only public ones. The paid version apparently requires read/write access to code due to limitations of the GitHub API for private repositories, which don't have a "read-only access to code" permission level.

Try adding from https://travis-ci.org/ instead.

From https://docs.travis-ci.com/user/github-oauth-scopes/:

Repositories on https://travis-ci.com (Private and public)

  • user:email (read-only) ...
  • read:org (read-only) ...
  • repo Grants read and write access to code, commit statuses, collaborators, and deployment statuses for public and private repositories and organizations. We need this level of access because GitHub does not provide the read:org (read-only) scope for private repositories.

Repositories on https://travis-ci.org

  • user:email (read-only) ...
  • read:org (read-only) ...
  • repo_deployment ...
  • repo:status ...
  • write:repo_hook ...

Thank you Brian! That makes a whole lot of a difference!