Not surprised.
Travis CI is owned by Idera, Inc. who also own Sencha who make Ext.js -- a pay-to-use JavaScript framework.
First thing they did when Idera, Inc. bought Travis CI? They gutted the Travis CI team.
Travis CI's new pricing plan threw a wrench in my open source works
21–30 of 148 posts
Re: Travis CI's new pricing plan threw a wrench in my open source works
#22While I have some sympathy. I also think that expecting travis-ci to effectively donate hours and hours of CPU time a month to endlessly run tests on hundreds on minor projects from one guy is exactly why this change happened. It's unsustainable.
Re: Travis CI's new pricing plan threw a wrench in my open source works
#23Not surprised. Travis CI is owned by Idera, Inc. who also own Sencha who make Ext.js -- a pay-to-use JavaScript framework. First thing they did when Idera, Inc. bought Travis CI? They gutted the Travis CI team.
That's Idera, if they buy anything you use, run!. Private Equity is all about milking the cow till the cow dies.
Re: Travis CI's new pricing plan threw a wrench in my open source works
#24I've been using Travis on a bunch of my opensource projects and was wondering why builds were getting queued for ~a day before they'd run, I guess I got my answer. :/ I don't really want to lock myself into GH actions (ideally, I wouldn't be on GH at all), does anyone have any suggestions for alternatives? I don't mind paying some money, but the almost $1K/year for Travis' lowest tier is about an order of magnitude m…
Azure Pipelines has been really good for us. Much much more reliable than travis, and decent pricing.
For self-hosted, I've heard really good things about build-kite (https://buildkite.com/) although I've not used it myself.
Re: Travis CI's new pricing plan threw a wrench in my open source works
#25Not surprised. Travis CI is owned by Idera, Inc. who also own Sencha who make Ext.js -- a pay-to-use JavaScript framework. First thing they did when Idera, Inc. bought Travis CI? They gutted the Travis CI team.
> who also own Sencha who make Ext.js -- a pay-to-use JavaScript framework.
I pity anyone who's paying for Ext.js (self-described as "The Best JavaScript Framework In The World"). That is some ancient shit right there. They must have some poor sods who're really, truly, stuck if they're managing to get people to pay for it. I guess at least you get support in your quagmire. But good luck finding quality developers who want to work on an Ext.js project...
Re: Travis CI's new pricing plan threw a wrench in my open source works
#26I don't know how the author could expect a free build service to last forever.
Re: Travis CI's new pricing plan threw a wrench in my open source works
#27The HN thread from when Travis's purchase by Idera (private equity) was announced, Jan 2019:
https://news.ycombinator.com/item?id=18978251
I had pretty much already learned that "bought by private equity" means "run away as fast as you can, they are going to gut it", and I suspected as much from the travis purchase... but I didn't take action, hoping it would not be true, and not wanting the work of moving projects away. Next time I'll remind myself, no, really, you know what "private equity" means, start looking for an escape now on your own timeline before circumstances give you a deadline.
Re: Travis CI's new pricing plan threw a wrench in my open source works
#28Earlier quoted context omitted.
Have you looked into CircleCI?
I've used it in the past, but when they finally killed off the 1.0 builders (?) my company went to an "internally" hosted Jenkins[1] server and I haven't played with any of the 2.0 stuff. Have you? How do you find working with it? [1] I did also ask about selfhosted stuff, but I'm not willing to host Jenkins for myself. I've heard nothing but complaints about managing a Jenkins install. It's been fine as a user (if a…
Not the person you're asking, but we use CircleCI, and it's fine. The YAML config language is okay, it gets the job done and hasn't been horrible to maintain or modify. Though we only have a few steps in each.
My current gripe is that there doesn't seem to be any way to declare that one pipeline depends on another, though I may just be missing something in the docs.
What I'm trying to do is have my front-end feature branch builds run against the build of matching back-end branch, but there doesn't seem a way to declare "this build should depends on the output artifact of that build".
I don't really want to have to wire it up myself using their API.
Re: Travis CI's new pricing plan threw a wrench in my open source works
#29Hey Jeff, This is hitting me hard, too. I hope this is the right moment for me to pipe up and say this: I always just do the minimum with these CI integrations to get my shell script to run. I am grateful for the free minutes they offer open source projects - but any of the deeper integrations, the advanced automation? No, thanks. It's not like the other developers who use what I write have any more motivation than I…
>do the minimum with these CI integrations to get my shell script to run This. 100%. Where I'm working is migrating from Bamboo to Jenkins. For my team the new process is just calling "./build-test $params" while others are stuck re-implementing various stages, tasks and blah blah blah. Also an added bonus to this is having the full history of changes to the CI/CD process tracked in git.
I call mine make.sh.
Now get off my lawn!
Re: Travis CI's new pricing plan threw a wrench in my open source works
#30Travis CI wasn't going to remain "free" forever, especially with the new owner (which owns Sencha as well). They want to make a profit, open source free builds are not making a profit.