Let me explain one big use case. I'm from CircleCi (hosted continuous integration - https://circleci.com) and this is really to help people like us out.
The problem this solves is that you need credentials to clone a git repo from GitHub. That's easy: you can add an SSH "deploy" key to the repo.
BUT, dependency management tools (like bundler, pip and npm) allow you specify private repositories in your Gemfile/requirements.txt/package.json file. If you use a deploy key, you won't have access to those repositories and your CI wil fail. This isn't a problem you face as a developer, because you have an SSH key on your machine valid for all your GitHub repositories, this only affects your CI server.
So now a 3rd-party hosted CI server can use an Oauth token - something we already have - to download any repository you have access to.
There were already some ways of doing this - we could have added an SSH key for your user. But this is easier, and you don't get a notification saying "Circle has added an SSH key to your account", which panics people. This is also more convenient in a couple of other ways which I won't get into.
But there is one final problem, and it's a big one: your CI server adds this key to the machine before it checks code out. Since you can run arbitrary code in the CI server, you could possibly steal the OAuth key, and act as the user. Uh-oh! You can try and prevent this, but it's a bit tricky and error-prone.
So what Circle does instead is make you explicitly opt-in to a user key. If you need to access multiple repos, we'll detect it, and tell you how to explicitly opt-in. This means you'll also get a notification saying "Circle has added an SSH key to your account" which is good in our opinion. Then we don't use that key for public repos, and only use it when _you_ are the pusher (your teammates will use their own key). We're also making that key passworded, which you can't do with OAuth.
That still isn't good enough for everyone. Some people prefer to specify a user to run all their tests, and that user has restricted permissions using GitHub's team management tool. This is great, and something we explicitly support as the most secure.
So I think this is great if you're using your own CI server and trust everyone who can commit code to it. For 3rd-party CI servers like Circle, I feel what we're doing is safer. Feedback welcome.
Finally, I don't want this to appear negative. The problem that I raised above is one that GitHub is aware of, and one they are solving. I can't say how they're solving it, but I know that it does indeed solve it. I believe this is step one, and a great move in the right direction.
Off-topic, but I saw your comment and I've been looking for a good CI solution that integrates with Github, and this was my first introduction to CircleCi.
I find it really off-putting that it's not possible to find out what your pricing plans are without signing up (and signing up requires giving you write access to my GitHub account).
Hey Daave, I agree completely. We have a stupid technical problem where our inner and outer pages are separate apps, and we need to merge them to show the pricing on the outside. Stupid I know. We're fixing it.
I went from knowing nothing about CI to setting up a full build job that deploys our various projects to multiple servers in a span of a few hours. What is the use case for hosted CI?
You can set up hosted git in a few hours. What is the use case of GitHub?
You can set up a server in a few hours. What is the use case of Heroku?
So the first use case of Circle is that you can set it up in seconds. Literally, 20 seconds. You spent a few hours setting up your CI servers, but what if you didn't have a server available, didn't know how to set up postgres, couldn't put a hole in your firewall for the github notifications, or forget to add "bundle exec" to your rspec calls?
Aha you think - I'll use EC2. So you rent a server (for the same cost as Circle), set up Jenkins, but somehow your tests keep failing. But only sometimes. Why is that? It's because EC2 has such ridiculously bad IO that your integration tests time out while logging into the server.
OK, so solve that problem, then your organization grows to 5 people, and your test suite to 5 minutes. You all push code one day, and now have to wait 25 minutes to get test results.
Then tests grow to 20 minutes, and the team to 12. Now you're in a deep hole, and you're bringing up servers as fast a you can, trying to remember how to configure them the same, and of course you've moved to a different project so it's actually your coworker doing it, and he doesn't know what you did.
We solve every problem here - easy to set up, incredibly fast, auto-scaling, and we can even parallelize your builds so that a 60 minute test suite on your machines runs across 4 machines and takes 13 minutes.
And Circle (again, at https://circleci.com) won't go down if you go on vacation.
It only took a few hours because I had no idea how Jenkins worked or what it did or how to write jobs. I use github because it has a lot of nice UI features on top of Git plus the social stuff and the fact that it's my resume. Maybe one day we'll be doing continuous integration to production and I'll look at your product.
(btw the github counter thing isn't very accurate)
This seems like it'd be useful for using private forks of gems on Heroku, since you could just check that app key into your Gemfile. Right? Or am I misreading this.
The problem this solves is that you need credentials to clone a git repo from GitHub. That's easy: you can add an SSH "deploy" key to the repo.
BUT, dependency management tools (like bundler, pip and npm) allow you specify private repositories in your Gemfile/requirements.txt/package.json file. If you use a deploy key, you won't have access to those repositories and your CI wil fail. This isn't a problem you face as a developer, because you have an SSH key on your machine valid for all your GitHub repositories, this only affects your CI server.
So now a 3rd-party hosted CI server can use an Oauth token - something we already have - to download any repository you have access to.
There were already some ways of doing this - we could have added an SSH key for your user. But this is easier, and you don't get a notification saying "Circle has added an SSH key to your account", which panics people. This is also more convenient in a couple of other ways which I won't get into.
But there is one final problem, and it's a big one: your CI server adds this key to the machine before it checks code out. Since you can run arbitrary code in the CI server, you could possibly steal the OAuth key, and act as the user. Uh-oh! You can try and prevent this, but it's a bit tricky and error-prone.
So what Circle does instead is make you explicitly opt-in to a user key. If you need to access multiple repos, we'll detect it, and tell you how to explicitly opt-in. This means you'll also get a notification saying "Circle has added an SSH key to your account" which is good in our opinion. Then we don't use that key for public repos, and only use it when _you_ are the pusher (your teammates will use their own key). We're also making that key passworded, which you can't do with OAuth.
That still isn't good enough for everyone. Some people prefer to specify a user to run all their tests, and that user has restricted permissions using GitHub's team management tool. This is great, and something we explicitly support as the most secure.
So I think this is great if you're using your own CI server and trust everyone who can commit code to it. For 3rd-party CI servers like Circle, I feel what we're doing is safer. Feedback welcome.
Finally, I don't want this to appear negative. The problem that I raised above is one that GitHub is aware of, and one they are solving. I can't say how they're solving it, but I know that it does indeed solve it. I believe this is step one, and a great move in the right direction.