Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jeffgeerling.com

Post reply on HN
Print view View original

71–80 of 148 posts

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

#71

Post by luord »

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 from lack of experience, as I've only set up actions in one project so far.

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

#72

Post by vosper »

driverdan wrote: post #38
vosper wrote: post #28

Earlier quoted context omitted.

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.

Yeah, it's separate repos. Interesting to know about the monorepo option, though - thanks.

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

#73

Post by qppo »

sounds wrote: 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…

Once you start caring about cross-platform, incremental, distributed builds with a bunch of people committing to a monorepo those advanced features start becoming attractive. Shell scripts handle the 'run this build/test task' but not 'pull these artifacts from another set of tasks, run this task to produce a bunch more artifacts, cache them for later.'

In these scenarios the lines between build system, package manager, and task runner all become pretty blurred. Haven't found an all in one solution that I would call "portable" yet.

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

#74

Post by emptysea »

qppo wrote: post #73
sounds wrote: 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…

Once you start caring about cross-platform, incremental, distributed builds with a bunch of people committing to a monorepo those advanced features start becoming attractive. Shell scripts handle the 'run this build/test task' but not 'pull these artifacts from another set of tasks, run this task to produce a bunch more artifacts, cache them for later.' In these scenarios the lines between build system, package manag…

Sounds like your describing what I like to call a fancy build system

Something like Bazel[0], Buck[1] Pants[2], etc. One of their main features is robust caching of build artifacts, which is helpful for larger projects. But they require some major investment compared to your typical `scripts/build.sh`.

[0]: https://bazel.build [1]: https://buck.build [2]: https://www.pantsbuild.org

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

#75

Post by qppo »

emptysea wrote: post #74
qppo wrote: post #73

Earlier quoted context omitted.

Once you start caring about cross-platform, incremental, distributed builds with a bunch of people committing to a monorepo those advanced features start becoming attractive. Shell scripts handle the 'run this build/test task' but not 'pull these artifacts from another set of tasks, run this task to produce a bunch more artifacts, cache them for later.' In these scenarios the lines between build system, package manag…

Sounds like your describing what I like to call a fancy build system Something like Bazel[0], Buck[1] Pants[2], etc. One of their main features is robust caching of build artifacts, which is helpful for larger projects. But they require some major investment compared to your typical `scripts/build.sh`. [0]: https://bazel.build [1]: https://buck.build [2]: https://www.pantsbuild.org

I have a lot of ideas (or rather, one idea) about how to fix my CI problems and "fancy build system" is pretty apt. Bazel is the closest thing I've seen to what I want.

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

#76

Post by aprdm »

saurik wrote: post #61
redis_mlc wrote: post #29

Earlier quoted context omitted.

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

I wouldn't want something called "make.sh" to install tooling on the computer, though, and that is an important step of CI stuff.

Run it in a docker container so that it does the same in your computer and in the CI worker.

make prepare

make build

make test

make release

Working the same waylocally and in jenkins makes things very easy.

What it does is up to the team but make prepare usually pulls some docker image and install dependencies, make build builds something inside the docker image, make test runs test inside it and make release publishes the docker img

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

#77

Post by brabel »

emptysea wrote: post #74
qppo wrote: post #73

Earlier quoted context omitted.

Once you start caring about cross-platform, incremental, distributed builds with a bunch of people committing to a monorepo those advanced features start becoming attractive. Shell scripts handle the 'run this build/test task' but not 'pull these artifacts from another set of tasks, run this task to produce a bunch more artifacts, cache them for later.' In these scenarios the lines between build system, package manag…

Sounds like your describing what I like to call a fancy build system Something like Bazel[0], Buck[1] Pants[2], etc. One of their main features is robust caching of build artifacts, which is helpful for larger projects. But they require some major investment compared to your typical `scripts/build.sh`. [0]: https://bazel.build [1]: https://buck.build [2]: https://www.pantsbuild.org

Gradle can also do everything imaginable, we've managed to get rid of basically all our horrible bash scripts and wrote most build stuff using Gradle API and using a proper programming language (put actual code in Gradle's buildSrc/, only configure it in build.gradle, and you've got a extremely powerful build).

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

#78

Post by gmemstr »

013a wrote: post #18
azdle wrote: post #9

I'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…

Github Actions really is a freakin awesome product. Yeah, there's lock-in, but their free plan (and cheap Pro plan for individuals) offers a great value. And, really, CI is CI; if you ever need to migrate, even for this guy with hundreds of projects it should only take a couple days. Once you've seen one CI yaml file, you get the gist of what all of them do. Other options: * Gitlab CI. Good value, great integration w…

Hey, one of the people responsible for orbs (primarily writing and maintaining our first-party ones) - curious if you can elaborate on "infamous for stability issues". Obviously it's hard to argue against the lock in, but I am aware that GitHub Actions has a similar system.

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

#79

Post by Joeri »

vosper wrote: post #25
weka wrote: post #21

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.

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

I worked with extjs 2 and 3 for years and honestly productivity was as high or higher than angular or react. It was a game changer and allowed us to build things an order of magnitude faster than before. I really liked it. What it lacked was a good responsiveness story, and by the time they added that I was already gone, first to backbone and later to angular and react.

The amount of vendor lock-in of Extjs is massive though. It had its own JSX-like pseudolanguage for describing UI that was impossible to port to anything else. Moving away meant a total rewrite.

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

#80

Post by laumars »

aprdm wrote: post #76
saurik wrote: post #61

Earlier quoted context omitted.

I wouldn't want something called "make.sh" to install tooling on the computer, though, and that is an important step of CI stuff.

Run it in a docker container so that it does the same in your computer and in the CI worker. make prepare make build make test make release Working the same waylocally and in jenkins makes things very easy. What it does is up to the team but make prepare usually pulls some docker image and install dependencies, make build builds something inside the docker image, make test runs test inside it and make release publish…

Or use a CI/CD tool that natively supports Docker, like Concourse.

Added bonus is that pipelines are defined in YAML rather than web GUI so you can version control the pipelines themselves and not just any build or test suites.

Post reply on HN