Live data from Hacker News

Travis CI's new pricing plan threw a wrench in my open source works

jeffgeerling.com

31–40 of 148 posts

Re: Travis CI's new pricing plan threw a wrench in my open source works

#31

Oh 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…

All three companies I worked for that ended up paying for a beefy Travis CI enterprise plan did so after getting hooked through the open source offering and wanting more concurrent runners and faster builds.

Without that funnel, and knowing it's all integrated deeply in both GitLab and GitHub, I wonder where Travis CI could ever expect growth again... but that's probably not the end goal anymore, just milking the current paying clients and maintaining the status quo.

Re: Travis CI's new pricing plan threw a wrench in my open source works

#32
post #8

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

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

Can't those stages, tasks, etc. be specified in the CI specific config files of the repository? Specifying them via an UI seems horrible to me. At least Github actions is all file-specified (except for secrets).

Re: Travis CI's new pricing plan threw a wrench in my open source works

#33

I don't know how the author could expect a free build service to last forever.

I don't. And as I said in the post, I'm extremely grateful for what I got.

I was already migrating projects for a while, and long term may even go back to a local server for builds if GitHub pulls the rug out too. But allowing a service to manage the build system for me saved/saves a good chunk of time.

Re: Travis CI's new pricing plan threw a wrench in my open source works

#34
> Should you want to apply for these credits please open a request with Travis CI support stating that you’d like to be considered for the OSS allotment. Please include:

> Your account name and VCS provider How many credits (build minutes) you’d like to request (should your run out of credits again you can repeat the process to request more or discuss a renewable amount)

Sounds like a tedious, repetitive process. If only there were a way to automate creating support tickets on a schedule...

Re: Travis CI's new pricing plan threw a wrench in my open source works

#35
post #14
post #10

Earlier 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…

We use circle for a lot of stuff (the latest version). It's pretty easy to learn. You can pick up the basics in <30 min.

Re: Travis CI's new pricing plan threw a wrench in my open source works

#36

After some of the previous TOS changes, I finally found the motivation to move to a self-hosted CI on a VPS. I’ve been entirely satisfied since migrating, and it’s been a truly low touch experience. Not for everyone I’m sure but for the low cost of the VPS I’m getting my value out of it, certainly not proving to be a maintenance drain as I’d feared, just updating it on a CRON has served me well.

Are there good tools to help with this for people who are used to a hosted CI and want to replicate some of its features? (I'm just curious, I'm not in that situation myself.) Or is the cloud/SaaS instinct so pervasive now that very few people are trying to do what you're doing?

Re: Travis CI's new pricing plan threw a wrench in my open source works

#37

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

I call mine make.sh. Now get off my lawn!

Hey! I started with C projects and make scripts and I long for the simplicity of those days! Obtuse web front ends, bunches of build server pools segregated by random capabilities, job queues clogged by competing developer teams and on and on is no fun.

Re: Travis CI's new pricing plan threw a wrench in my open source works

#38
post #28
post #14

Earlier quoted context omitted.

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…

If they're in the same repo you can do this using workflows. If they're separate repos I don't think you can do this without using their API.

Re: Travis CI's new pricing plan threw a wrench in my open source works

#39
post #4

> For almost a decade, Travis CI made it possible for me to build—and maintain, for years—hundreds of open source projects. Then what about paying for it? The service is definitely very valuable to this person.

The point is, like with almost all open source work, the funding has to come from somewhere.

If I'm an open source software maintainer, and I make a project that is used by 3,000 companies, helping them generate $Xmm in revenue... how much of that money ever trickles back to the maintainers? The typical answer is $0.

Some maintainers are lucky to have some form of corporate sponsorship, others spend many cycles on some form of marketing to build up some kind of financial support (tip jars, Patreon, etc), but the pricing for Travis is astronomical for non-enterprise usage.

But as I said in the post, I'm grateful for what I got for the 8 years I had it. And I'm happy that GitHub/MS is now running with that gauntlet.

Re: Travis CI's new pricing plan threw a wrench in my open source works

#40
post #7
post #4

> For almost a decade, Travis CI made it possible for me to build—and maintain, for years—hundreds of open source projects. Then what about paying for it? The service is definitely very valuable to this person.

This. If I had a cloud hosted CI tool, I would gladly allow open source projects to use it. But they would be lowest priority and there would be limitations on how often builds could happen and/or volume of contributions. Large corporate backed opensource projects should absolutely be paying for tools like Travis CI. Just because it's open source doesn't mean there isn't money floating around. It's not super hard to…

It's not the setting it up that's preventing someone like me from self-hosting these kinds of tools. It's the maintenance, security, accessibility, etc.

More time on all that (or risking hacks and having more downtime) equals less time actually working on the projects being tested.

Post reply on HN