It might be because I'm more familiar with the syntax, but I find gitlab-ci easier to reason about than github actions. At least, it's a single file instead of a workflow and any number of actions. This is to say, if I were in Jeff's situation, I would seriously consider moving to GitLab (with mirrors in github for visibility), or at least setting up their ci to trigger from github. Though maybe I'm just speaking fro…
Travis CI's new pricing plan threw a wrench in my open source works
121–130 of 148 posts
Re: Travis CI's new pricing plan threw a wrench in my open source works
#122Oh boy, I just moved my projects from travis-ci.org to travis-ci.com after the builds stopped happening on .org. (Despite the travis FAQ that said "we’re making a number of changes to the travis-ci.org infrastructure to ensure the service will remain as reliable and available to you as it always has been until [it goes away Dec 31]", that was not the case, builds simply stopped working on .org. https://docs.travis-ci…
Of course we can, we just down't want to.
Re: Travis CI's new pricing plan threw a wrench in my open source works
#123Re: Travis CI's new pricing plan threw a wrench in my open source works
#124Travis 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.
Re: Travis CI's new pricing plan threw a wrench in my open source works
#125Earlier quoted context omitted.
Well, their lowest paid tier is $69/month. I dunno about you, but that's way more than I can justify spending to be able to support doing work for free. If they had a $50/year or so plan that just restored the previous open source plan, I'd be more willing to consider something like that, but >$800 a year puts it firmly out of my price bracket for what it offers me.
This. I am willing to pay but there's no way I can spend my yearly "save for a new laptop every couple years" budget on one SaaS for projects that generally contribute $0.00 to my bottom line.
I can totally understand limiting the number of minutes available. It must cost an absolute fortune, and having it unbounded makes it easy to abuse. Having to pay makes developers have to consider if they really need to go overboard on huge build matrices and limit themselves to something reasonable. Likewise for constraining the amount of network traffic. If you don't want to blow your budget, then self-hosting is an obvious and easy choice.
Re: Travis CI's new pricing plan threw a wrench in my open source works
#126I don't understand this reaction and the reaction of many people in this thread. To me it looks like choosing beggars, maybe I'm missing something. Travis-CI was giving a ton of computing power for free, no questions asked. That was incredibly generous but had certainly a gigantic cost and it powered many OSS projects for a long time. Yet how can we complain that they can throw money around, some says that it will re…
Not sure if would work, but it might be worth trying to have some kind of "donate CI time for this project" button on the platform. Could be onetime payment or a recurring donation (charged together with whatever payments you have for the platform).
I agree with the parent comment, it’s bizarre to blame this on the new acquiring company and to be mad about this development. Travis ci has been asleep at the wheel for many years, and projects have been benefiting from it with huge amounts of free compute for years, but now the free money has run out.
Re: Travis CI's new pricing plan threw a wrench in my open source works
#127Re: Travis CI's new pricing plan threw a wrench in my open source works
#128Hey 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…
Makefiles are the gold standard there, warts and all. But in every case, unless you encode a whole plethora of hacks in your golden build script, you still need minimal environment setup, like Python + Docker + [insert library here]. Most of my Travis files are only 10-20 lines long, but I work in a lot of different types of environments, so it's not always as easy as "three lines of bash and a docker run command". P…
We've actually migrated all our projects off Makefiles. Developers hate having to live within the constraints.
Re: Travis CI's new pricing plan threw a wrench in my open source works
#129I don't understand this reaction and the reaction of many people in this thread. To me it looks like choosing beggars, maybe I'm missing something. Travis-CI was giving a ton of computing power for free, no questions asked. That was incredibly generous but had certainly a gigantic cost and it powered many OSS projects for a long time. Yet how can we complain that they can throw money around, some says that it will re…
Effectively removing or severely restricting that benefit will essentially lose the goodwill and word of mouth marketing.
It's true that to criticise someone giving you something for free is being a "choosing beggar", but that's not really what's happening here. TravisCI has bought something with their free offering, so it's fair that they lose that when they revoke that offering.
Re: Travis CI's new pricing plan threw a wrench in my open source works
#130Earlier quoted context omitted.
>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.
Are you moving to Jenkins because of the recent Atlassian license changes?