Travis CI integrated into GitHub pull requests thanks to new Commit Status API(github.com)
github.com
Travis CI integrated into GitHub pull requests thanks to new Commit Status API
https://github.com/blog/1227-commit-status-api
5 comments
I love this a lot, but I would love this more if GitHub bought up Travis so I can do things like have Travis run on private repositories.
I'm really glad Travis has such awesome sponsors keeping them alive, but I think most paying customers of GitHub would be more than happy to pay an extra $5 a month or something to have priority queuing on Travis, and ability to run on private repos and such. With build checking brought in-house, I really don't know what else GitHub would be missing from the overall process of checking in code.
I'm really glad Travis has such awesome sponsors keeping them alive, but I think most paying customers of GitHub would be more than happy to pay an extra $5 a month or something to have priority queuing on Travis, and ability to run on private repos and such. With build checking brought in-house, I really don't know what else GitHub would be missing from the overall process of checking in code.
> I really don't know what else GitHub would be missing from the overall process of checking in code.
CI as-a-service is a massive undertaking, and requires different focus from what GitHub is currently doing. Three main differences are
1) lots and lots of devops. You have to support dozens of ruby, python, php versions. You have to support the version that Heroku uses, the one that EY uses, the one that AppFog uses. Same with databases. Then you have to somehow deal with the fact that gems that compile on Ubuntu 10.04 don't compile on Ubuntu 12.04
2) Then you have to make all of the above fast. We (I'm one of the founders of CircleCI https://circleci.com) spent months improving build speed, to make a compelling product. People don't pay for build results that take longer than their laptop can provide.
3) CI-aaS is high touch. A large percentage of new users will have lots of support in their first month. We don't track this stat yet, but Jason Cohen (founder of WPEngine) does, and his customers require 4x the support in their first month , compared to existing users.
3) Doing this well costs (and is worth) more than git hosting. It'd be a little strange for GitHub to buy a CI product, and then charge 2-10x for CI what they do for github.
4) GitHub has released multiple OSS CI products, and their employees have told me they don't think it makes sense to do hosted CI.
So I'm not holding my breath for an acquisition. But in the meantime, you can start testing on CircleCI today.
CI as-a-service is a massive undertaking, and requires different focus from what GitHub is currently doing. Three main differences are
1) lots and lots of devops. You have to support dozens of ruby, python, php versions. You have to support the version that Heroku uses, the one that EY uses, the one that AppFog uses. Same with databases. Then you have to somehow deal with the fact that gems that compile on Ubuntu 10.04 don't compile on Ubuntu 12.04
2) Then you have to make all of the above fast. We (I'm one of the founders of CircleCI https://circleci.com) spent months improving build speed, to make a compelling product. People don't pay for build results that take longer than their laptop can provide.
3) CI-aaS is high touch. A large percentage of new users will have lots of support in their first month. We don't track this stat yet, but Jason Cohen (founder of WPEngine) does, and his customers require 4x the support in their first month , compared to existing users.
3) Doing this well costs (and is worth) more than git hosting. It'd be a little strange for GitHub to buy a CI product, and then charge 2-10x for CI what they do for github.
4) GitHub has released multiple OSS CI products, and their employees have told me they don't think it makes sense to do hosted CI.
So I'm not holding my breath for an acquisition. But in the meantime, you can start testing on CircleCI today.
Hello, I cannot easily find your pricing page. This is a non-starter when trying to convince our org to use CircleCI. Am I blind? Need this info before I can move forward.
You're right, sorry. This is a technical limitation for now (the inner and outer are separate apps). We're merging them real soon now. We start at $20/month for one project and scale up from there. We offer bigger plans for more projects, more concurrent builds, and auto-parallelization.
Login and go to the settings > plan page:
https://circleci.com/account/plans
https://circleci.com/account/plans
Nope, this page needs to be outside the login wall. I'm not creating an account just to see pricing levels.
I love Travis as well and use it on a lot of open-source projects I'm a contributor to, but I've been using CircleCI for private repos so far and really love what they do. I'd absolutely recommend checking it out: https://circleci.com/
It'll be interesting to see how the hosted CI market takes off - I thought CloudBees was going after it for awhile, but it seems they haven't pushed too hard, while there have been a lot of new entrants over the past year. Good time to be a developer, that's for sure.
It'll be interesting to see how the hosted CI market takes off - I thought CloudBees was going after it for awhile, but it seems they haven't pushed too hard, while there have been a lot of new entrants over the past year. Good time to be a developer, that's for sure.
Agreed, we've been using https://railsonfire.com/ for our private repos - good to see the competition heating up in the space.
It looks like Travis has a "pro" edition coming, but the link goes to a placeholder page ATM
http://about.travis-ci.org/docs/user/travis-pro/
http://about.travis-ci.org/docs/user/travis-pro/
Oh, neat!
I think there is an aspect which I didn't mention of "Who do you trust with your code?" and GitHub has done well to earn the trust of lots of great companies, but I can certainly see IT managers getting a bit ancy at adding another point of confidentiality failure by looping in Travis as well.
I think there is an aspect which I didn't mention of "Who do you trust with your code?" and GitHub has done well to earn the trust of lots of great companies, but I can certainly see IT managers getting a bit ancy at adding another point of confidentiality failure by looping in Travis as well.
Maybe "Enterprise" accounts could have VMs with FDE; Travis gives them a bare image that's then encrypted w/ a user-provided key, so (barring a hostile attack on the host's memory) only the user has access to their data.
Though the same users that want such a thing are likely also running (locally hosted) GitHub Enterprise, it'd make more sense to provide a similar option for Travis.
Though the same users that want such a thing are likely also running (locally hosted) GitHub Enterprise, it'd make more sense to provide a similar option for Travis.
The Travis Pro edition has been being used actively by customers for almost two months now, we're just not making a big fuss about it because we focus on ironing out kinks :)
If you're interested, you're more than welcome to get in touch with us ([email protected]).
Mathias/Travis CI
If you're interested, you're more than welcome to get in touch with us ([email protected]).
Mathias/Travis CI
That's right - I'm in the beta and it works really well.
Thank you for your kind words, they're very humbling and flattering for us, and they are what keep us going. It's a great boost for us that people suggest GitHub should buy us. Thank you!
Thank you for your suggestions as well, it's something we've been thinking about ourselves as well, independently of whether it's a part of GitHub or an independent project/product.
We've been working hard on making Travis CI available for building private GitHub repositories, and we're coming along quite nicely. Stay tuned! :)
Mathias/Travis CI
Thank you for your suggestions as well, it's something we've been thinking about ourselves as well, independently of whether it's a part of GitHub or an independent project/product.
We've been working hard on making Travis CI available for building private GitHub repositories, and we're coming along quite nicely. Stay tuned! :)
Mathias/Travis CI
This is only for rails projects, but we use semaphore for about a month or so on our private repository, and it's really sweet. Very simple and clean interface. Nicely customizable, and the support guys are really great too (they customized the version of redis just for our project and basically really help out on any question). I don't work for them, or get anything out of recommending their service, but we're really happy with the service so far. Price is a little higher than $5 a month, but still quite reasonable.
any particular reason to downvote this? (noticed that the other mention of semaphore got downvoted too). It would be nice to know why. I'm relatively new to HN, but haven't had much stuff downvoted, and not sure what might be wrong with my comment.
Great to see Travis supporting Pull Requests.
At Mozilla we've been using Bot.io for several of our Github projects (PDF.js, Firefox OS, Popcorn.js, etc) since mid-2011 to launch regression tests right from Pull Requests. It's fully customizeable (runs on Windows, Linux, Mac, etc), open source, and a breeze to install:
http://github.com/arturadib/botio
We'll likely be implementing the status API very soon. Let me know if I can help at @arturadib.
At Mozilla we've been using Bot.io for several of our Github projects (PDF.js, Firefox OS, Popcorn.js, etc) since mid-2011 to launch regression tests right from Pull Requests. It's fully customizeable (runs on Windows, Linux, Mac, etc), open source, and a breeze to install:
http://github.com/arturadib/botio
We'll likely be implementing the status API very soon. Let me know if I can help at @arturadib.
I think BuildHive (https://buildhive.cloudbees.com/) supports Pull Requests too. I'm using for my repositories, and I have an internal Jenkins server for private repositories.
Yes, they do: https://github.com/jenkinsci/github-plugin/pull/17
Kohsuke Kawaguchi (the creator of Jenkins) has added this API to his Java library for Github: https://github.com/kohsuke/github-api/commit/892d2acaa2ca737... So, it's just a matter of time until that trickles downstream to the plugin and BuildHive.
Kohsuke Kawaguchi (the creator of Jenkins) has added this API to his Java library for Github: https://github.com/kohsuke/github-api/commit/892d2acaa2ca737... So, it's just a matter of time until that trickles downstream to the plugin and BuildHive.
For all who use Ruby and want to have great CI of private projects today, Semaphore (https://semaphoreapp.com) already implemented support for this awesome API: http://renderedtext.com/blog/2012/09/04/semaphore-implements....
CircleCI (www.circleci.com), which we use has similarly promised this functionality in the coming day.
This makes it impractical for certain types of business.