TL;DR: Travis CI is no longer free for open source projects. Instead you get a free trial good for 1k build minutes, and can email them to beg for more when those run out.
The new pricing model for Travis CI
31–40 of 88 posts
Re: The new pricing model for Travis CI
#32It seems GitLab CI/CD is beating Travis CI on pretty much every metric now, except the weirdness of only using GitLab for CI/CD and not code hosting, if you prefer to use GitHub for that. Am I missing something? (GitLab supports using its CI/CD on a non-GitLab repo just fine, but it can cause some initial confusion.)
Is GitLab CI/CD substantially better than GitHub Actions, do you know?
From my experience of using both I prefer Github actions and consider it better. Person opinion and experience of using both.
Re: The new pricing model for Travis CI
#33It seems GitLab CI/CD is beating Travis CI on pretty much every metric now, except the weirdness of only using GitLab for CI/CD and not code hosting, if you prefer to use GitHub for that. Am I missing something? (GitLab supports using its CI/CD on a non-GitLab repo just fine, but it can cause some initial confusion.)
Is GitLab CI/CD substantially better than GitHub Actions, do you know?
I've used both, and it seems like both work equally well for the way I want to use it. I prefer to use GitLab because it's open source. Admittedly I haven't used the open source version of GitLab much, but it's nice to know that it's there. It includes CI/CD:
> CI/CD is a part of both the open source GitLab Community Edition and the proprietary GitLab Enterprise Edition
https://about.gitlab.com/stages-devops-lifecycle/continuous-...
As I start to use more advanced features of CI/CD, I might get a better idea of how they compare. I am aware that GitHub Actions has a marketplace but I don't really want to set up my builds that way. I would rather write the steps myself, pulling in docker images and packages from package managers like npm, PyPI, and apt as needed.
Re: The new pricing model for Travis CI
#34It seems GitLab CI/CD is beating Travis CI on pretty much every metric now, except the weirdness of only using GitLab for CI/CD and not code hosting, if you prefer to use GitHub for that. Am I missing something? (GitLab supports using its CI/CD on a non-GitLab repo just fine, but it can cause some initial confusion.)
Travis CI has unique feature - support for ARMv8, PowerPC, and SystemZ build environments. GitHub doesn't have this multiplatform building environment.
https://github.com/uraimo/run-on-arch-action
It's on qemu, not that fast but it works.
Re: The new pricing model for Travis CI
#35It seems GitLab CI/CD is beating Travis CI on pretty much every metric now, except the weirdness of only using GitLab for CI/CD and not code hosting, if you prefer to use GitHub for that. Am I missing something? (GitLab supports using its CI/CD on a non-GitLab repo just fine, but it can cause some initial confusion.)
Is GitLab CI/CD substantially better than GitHub Actions, do you know?
From my experience, writing a custom driver for GitLab Runner is a lot easier, if you need to support custom setup.
They also differentiate heavily on how they work. With GitLab, if you for example want to run jobs on ephemeral KVM virtual machines, you would have an agent on host machine (or multiple of them), which would then receive a job, spawn VM, execute commands in it, and at the end terminate it.
With GitHub, you would have to spawn VMs in advance, and launch their agent in each of them. When agent dies, you will have to manually kill the VMs, and spawn a new one.
This means that there is no easy way to have VMs spawn on demand, or to spawn different VMs with different configurations depending on job label.
Re: The new pricing model for Travis CI
#36I guess this is the same pricing model as CircleCI? I've always found "build minutes" to be a little bit of a vendor-favored pricing model. I really love wanting to do a release, and watching my CI provider take three minutes to pull down a 30MB docker image, or "npm install" running at dialup speeds. All while they're billing you per minute -- they make money by not investing in their infrastructure! I'd prefer to p…
> slow CI is probably the biggest engineering time killer in existence
If you're at the size where slow CI negatively affects your projects, then you're big enough to own your own CI (at least the build agents).
Remember that one-man projects don't need CI, and that CI for small (n<5) teams is almost never the bottleneck. These SaaS CI providers really target the open-source / small-team market and it makes sense that they wouldn't optimize for larger-scale operations.
Re: The new pricing model for Travis CI
#37Earlier quoted context omitted.
Does that actually make sense, or is it just another Engineering team doubling down on their poor early architectural choices ("or lack thereof")?
My understanding is that they needed some of the functionality in CoreGraphics, thus had to use Macs.
Which, if it allows them to get better quality results with less engineering time, could totally turn out to have been a sensible business decision.
(no idea beyond "could", but it does at least seem plausible)
Re: The new pricing model for Travis CI
#38For OpenFaaS (and other projects - k3sup, arkade, inlets etc) paying for Travis isn't going to be an option, as they are open source and unfunded. The Travis platform means being able to have relatively portable CI that almost never needs to change because of the CI platform. Bring a Makefile and use it locally and in the build pipeline.
Moving off Travis to something like GitHub Actions will cost a significant amount of time and the opportunity cost is ridiculous.
This along with the Docker Hub limits makes a very strong case for GitHub's strategy.
Re: The new pricing model for Travis CI
#39I guess this is the same pricing model as CircleCI? I've always found "build minutes" to be a little bit of a vendor-favored pricing model. I really love wanting to do a release, and watching my CI provider take three minutes to pull down a 30MB docker image, or "npm install" running at dialup speeds. All while they're billing you per minute -- they make money by not investing in their infrastructure! I'd prefer to p…
> slow CI is probably the biggest engineering time killer in existence If you're at the size where slow CI negatively affects your projects, then you're big enough to own your own CI (at least the build agents). Remember that one-man projects don't need CI, and that CI for small (n<5) teams is almost never the bottleneck. These SaaS CI providers really target the open-source / small-team market and it makes sense tha…
I disagree with this.
Even a single project with 20-minute build times is enough to slow down or frustrate development.
At the same time, I would not easily justify spending time managing CI infrastructure with my team of 6-10 people.
Things may have changed since then, but the last time I self-managed build agents, it often lead to build jobs being tightly coupled to the build agent and installed software versions. With a docker-based CI system, you are forced to have everything specified in code, making it much more maintainable.
Additionally, hosted CI allows me to do 100 parallel builds on Linux, MacOS and Windows. Perhaps this is a niche use case, but I saved a lot of time and reduced build times by an order of magnitude by switching from self-hosted CI on Windows and MacOS to a hosted solution.