
Easier builds and deployments using Git over HTTPS and OAuth - nigma
https://github.com/blog/1270-easier-builds-and-deployments-using-git-over-https-and-oauth
======
pbiggar
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.

~~~
daave
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).

~~~
mattdeboard
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?

~~~
pbiggar
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.

~~~
mattdeboard
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)

------
zrail
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.

~~~
pbiggar
You are exactly right.

------
sitharus
That doesn't look like OAuth to me, it looks like application level passwords.

Looks like a great addition though, limiting scope is always a benefit

------
amccloud
Should be "Go forth and pull"

~~~
netherland
You're right. Updated.

