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. No one wants to learn the custom setup steps, not even for the "biggest" of the bunch. (Is that still Github? Who knows? I don't.)
Oh, and if or when I migrate away from a CI system, like right now... Good thing I just kept it simple, you know?
Even for builds that target Windows, I just run a shell script.
I get it that Node and Rust builds really benefit from the advanced features. Anyone care to comment - is it as portable as a shell script?
>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 think there will still be a on premise version of Bamboo going forward, but all the license changes have made my company consider the possibility of moving from Bamboo to something else. That's kind of a shame, because Bamboo works really well for us.
> 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).
I found these fascinating, I mean they still have lots of things in their ci file, but basically the have tons of shell scripts that would work without their gitlab-runner.
Not affiliated with gitlab I just tried to figure out how some of their stuff works to have the same k8s integration than their autodevops offers.
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.
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
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.
> Jenkins pipelines are written in Groovy and you do not need to use the web ui, everything is exposed via its API (i.e: new job creation).
There's several ways you can codify Jenkins pipelines, Groovy being just one of them. But ultimately it's secondary to the main design of Jenkins. I'm not taking anything away from Jenkins as a solution - it has been invaluable over the years. But the way we write, test and deploy software has changed since Jenkins rose in popularity and as such we need to rely on different workflows that utilise different tooling. While Jenkins can be used in that way, I'd sooner use something which was primarily designed to be configured via code and used docker by default rather than something that requires enforcement to follow those best practices. That doesn't necessarily mean Concourse, there's Travis, Circle CI, AWS CodeBuild and a bunch of others that all default to that kind of workflow too, but it does mean I'm unlikely to ever advocate Jenkins again in future jobs.
While you’re not wrong I do use jenkins inside docker and use ansible to configure it, it is a bit different than other more modern tools but works fine.
I have yet to see other tools be as flexible (perforce , git, legacy tools, docker, 100s of workers across datacenters etc.)
I’m yet to see a CI/CD tool that can’t do all of that. What you’re describing there is the bare minimum I’d expect any CI/CD solution to do. I guess there might be some hobby platforms for indie devs but they’re not really the use case we are discussing when talking about Jenkins and Concourse.
I've bounced off concourse several times now. The promise is great, but the setup is absurdly complex and at the end I'm stuck with CI in Docker containers (I usually want 1 or more VMs)
Concourse can run as many VMs as you want. The point is those jobs get pushed to a farm of workers (typically VMs) and then docker is used so you have an ephemeral and repeatable build environment. It is absurdly complex to set up though. I feel there is a gap in the market for a Concourse-like solution but simplified immensely.
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".
Plus I have a number of legacy projects which did use some of Travis' more exotic features, and those will take longer. Not just for myself, but I'm thinking of tons of smaller OSS libraries and projects that are minimally maintained yet have a large footprint under more popular and maintained software!
You want coworkers and collaborators to have such an easy time validating build failures locally that only an idiot or an asshole won’t do anything about a problem they may have caused.
Developers hate being thought of as idiots, and being an asshole is a problem you can take to HR. So for the people who don’t pitch in on general principle, straightforward processes help bring them around. And in general that means not leaning on clever CI features, and instead leaning hard on the CLI tools your ecosystem supports.
There are exceptions to every rule of course. Features around scheduling have little to no impact on what gets built and how, just when and why. Similarly, analytics have second order effects on how and when, but once a problem is discovered you can mostly ignore them for a while. Integration with external tools and services on the other hand, should always be questioned. Do I have another way to do this mostly outside of the CI system?
I don’t think either of them really “benefit from the advanced features” any more than any other language. Also, both have builds that are generally more cross platform than a shell script, given that they’re native on all platforms, and shell is not.
Small plug: consider using Toast [1] to define your CI jobs. It's essentially Make + Docker. You define whatever targets you want (build, test, lint, etc.) and the dependencies between them in a YAML file, and Toast runs them in Docker containers. You can run your jobs on any machine that has Docker—including CI systems like Travis and GitHub Actions. You aren't locked into any CI system, and you can also run your jobs locally.
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.
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`.
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).
Shebangs are also your friend, if your primary language can be used that way.
The cons of that solution are that there’s a tendency to make them ornate, and the trap of circular dependencies. Reusing an internal library in your build scripts, you have it building itself which can get out of hand quickly.
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.
I 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 reduce the number of new users that discover the service and the number of paying client in the long run (many are saying this but are not paying users anyway) but it's not like the number of potential clients is unlimited anyway and at what point it becomes to costly to get the last ones.
Why would this be a "private equity" thing, you can't always loose (or invest to get more users) money. Does your company sponsors the infrastructure of that many OSS projects? Would it be willing to cover the costs of all servers used by OSS projects for Travis?
TravisCI bought goodwill and marketing of their paid offering by offering free builds for open source products.
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.
There’s a lot of things Travis ci could do. This is a great idea to help offset their costs, they could also have made their platform better to bring in more paying companies. They haven’t at all kept up with competitors as tooling and build processes have evolved in the past 9 years (namely easy to use docker-native test environments, and parallelization options for big codebases).
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.
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.com/user/migrate/open-source-reposito...)
I actually had not seen that announcement at all, this is the first I'm seeing it. So I'm in the same position as OP, I maybe should not have spent time migrating my projects to travis-ci.com. Although I guess this buys me a bit of time to move to github actions instead.
Travis is the reason that many people DO CI at all, in my experience. They made it so easy -- and free for open source -- that there was no reason NOT to do it. Then once you see the value of it, you are hooked, you can't do without it. But I think the number of projects doing CI (open source and not) skyrocketed because of travis. Prior to travis's entry on the scene, CI was not nearly as universal as it is now.
So to say that offering free CI to open source is "unsustainable".... I dunno, they managed to do it for 9 years, were they losing money the whole time?
I think the free service for open source literally created the market. Or expanded it exponentially. It was the first exposure a lot of people had to CI, and they took that first step because it was so easy and free.
And now we're hooked. If there weren't other free alternatives like Github Actions, I don't know what open source would do... we all know we can't develop this stuff without CI, but so many open source projects simply don't have a budget for it.
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.
"that's probably not the end goal anymore, just milking the current paying clients and maintaining the status quo."
Yep, that's private equity. I won't forget it again.
If it makes less and less profit every year even that's probably fine, eventually they'll shut it down, as long as they made back a multiple of what they paid by that point, then it was a good investment.
It's sad to me just as an engineer, that travis is actually really well-built product, it works magnificently and sets a high bar for ease of use, because of many hours of work that developers who cared put into it... and it's now just going to be allowed to slowly sink into the sea.
Lately as I’ve been getting (more) frustrated with Bamboo and spending time noodling with kubernetes and JAMStack. I keep flirting with the notion that there’s a new generation of CI tool out there waiting to be discovered, one that steals a bit of brain- and problem-space from all three.
One that could more easily be set up by individuals, making it amendable to open source, possibly with some small degree of federation.
True. We have just learned what an advantage CI is to software quality and developer productivity, expectations for both of which have been raised because of pervasive use of CI.
Many people wound up discovering/learning that and raising expectations because Travis's extraordinarily easy-to-use and reliable, and free for open source service, got them to try it out and discover the benefits. People had been talking about how everyone should be doing CI before travis, but I think travis played a major role in significantly increasingly how many people were actually doing CI (and thus learning that they didn't want to do without it's benefits), changing the way software is developed. Which is to the credit of those who developed the original travis service, for sure.
I think it really created a market, by offering something with very low barriers that 'hooked' people. Now we're hooked.
I am rooting for the SourceHut CI[1][2][3]. Along with other services it has proven useful even at the current (alpha stage). Also it's the only one that supports both FreeBSD and OpenBSD (NetBSD support is unfinished [4])
At a glance, it doesn't seem to support neither Windows nor OSX, any ideas if it is supported with your own builder/runner or if sr.ht is working on supporting it in the future?
To plug another CI service, there is https://ci.cppget.org with focus on C/C++. It's free and unlimited for open source projects, including Windows and Mac OS.
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.
Pretty much any time there's an acquisition of a company, followed by a firing of a significant fraction of the engineering staff, one should run away from it.
Sucks though for Travis CI users, I used it in the past and it worked well.
> 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...
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.
I’m on my first gig involving front-end now, with ExtJS 3.4. A few years before I joined (was able to observe the team from a periphery) they tried using Sencha’s 3.x-to-4.0 migration tool, which left the app in a state still needing attention to every LoC. The post-Idera layoffs aren’t making 6.x look too attractive.
While 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.
This "one guy," if you will, is responsible for a majority of the ansible galaxy modules that are out there.
Far from a bad actor just utilizing CPU time for pet projects, Jeff's code is probably in use in a large majority of companies that use Ansible, mine included.
Bingoooooo. If his code is so crucial to your company, you should probably be donating to him to help pay these bills so then companies aren't the bad guy for giving thousands of dollars away for free so you can benefit off other peoples work.
100% this! People can’t possibly complain when companies charge for their tools. If an open source project is important to an organisation, they better start donating.
"Testing your open source projects will always be free! Seriously. Always. We like to think of it as our way of giving back to a community that connects so many people."
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?
If you’re comfortable with AWS or any other VPS provider, there are Ansible and Docker flavours of most common tools. I’m a fan of Jenkins but the competition also offers some well defined pathways to get this going easily, and all of them offer a somewhat similar way to define builds automatically in code. My go-to is the github org scanner plugin that can watch for new repos with a Jenkinsfile, and will happily manage creating the automatic commit hooks if a new one is found giving you a very similar level of ‘magic’ integration to what the SaaS tools offer.
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.
Travis has an FAQ whose URL says "open source repository migration", but whose on-page title says "Migrating repositories to travis-ci.com"
Travis Staff accounts in the travis "community forum" were linking to this FAQ as recently as 9 days ago, which still at this moment contains a question:
> Q. Will Travis CI be getting rid of free users? #
> A. Travis CI will continue to offer a free tier for public or open-source repositories on travis-ci.com and will not be affected by the migration.
This would seem to be grossly misleading, if not simply wrong info? There are still a bunch of travis users on travis community forums trying to figure out what's going on and why travis-ci.org seems to have stopped working (also different from what the FAQ says), who don't seem aware of the pricing change.
The first line of the document is "On May 2nd, 2018 Travis CI announced that open source projects will be joining private projects on travis-ci.com!", which also includes this FAQ:
> Q. Will there be lower concurrency for free accounts on travis-ci.org?
> A. As part of the shift of infrastructure from .org to .com and needing to make sure all users have equal access to resources, free and open-source .org accounts will have concurrency reduced from 5 to 4 concurrent jobs. Concurrent jobs have not changed on .com, so please consider migrating your repositories as soon as possible if this is an issue.
So... that's all not quite right, it turns out. They're providing an FAQ about "free accounts" without saying there no longer is no such thing as a free account, and "open source projects" are "joining private projects on travis-ci.com" only in the sense they can choose to pay for the same plans as private projects.
It's true that nobody owes us anything for free, and the free support for open source CI for the past 9 years has been a gift...
It's also true that they are not being particularly transparent (an understatement; if they don't fix that FAQ soon I'm just going to call it lying) or gracious in how they are handling this transition, for an open source community that has come to rely on them.
This is what hurt the most. I knew the migration to .com was happening. And I expected the perks (like 5 concurrent jobs) to be slowly removed over time.
But to go from the status quo to 1000 build minutes and that's it in one day, with literally no lead time.
That's what caused the wincing. I'm sure many of the engineers who were laid off at Travis after the buyout are shaking their heads this week.
I expected perhaps they would eventually limit the number of build minutes you got per month.
I honestly did not expect they would eliminate free CI for open source altogether. With virtually no notice. Many people STILL haven't noticed the announcmeent, the FAQ is still misleading them.
> They're providing an FAQ about "free accounts" without saying there no longer is no such thing as a free account, and "open source projects" are "joining private projects on travis-ci.com" only in the sense they can choose to pay for the same plans as private projects.
Mouse over the (?) icon. "Free plan is trial plan. The credits will not be replenished. Switch to Free Plan if you want to cancel your subscription."
So, yeah, there is something they call the "free plan". If gives you 10K "credits" that once they are gone they are gone (I'm not sure exactly what a "credit" corresponds to in terms of workers/minutes, but could probably find it somewhere).
Do you feel like this is what you expected it to be, that they are being transparent about the fate of open source projects that previously had free CI? You can say you do, it's your perspective!
Because it's easy to use, it works well, and when it doesn't there are 3 other competitors ready to take over.
Travis CI could shutdown overnight, there's Circle CI and AppVeyor doing the exact same thing. They take pretty much the same configuration so there's nothing to adjust.
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 more than I can justify. I've also got plenty of compute laying around if anyone has suggestions for something self-hosted.
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 with Gitlab, has integration with Github.
* CircleCI. Something of a gold standard in CIaaS among growing companies. But, it goes down a lot, and the new UI isn't an improvement. But, it works and its a good value. Word of advice, I'd avoid using their "Orbs" if I were you. You can accumulate a lot of lock-in with those, and they're infamous for stability issues. Instead, use their docker builder and just build a base docker image with all the stuff you need installed.
* Buildkite. Really cool product; they handle the control plane and the UI and webhooks, you host the runners. Its a simple binary or docker image you can install anywhere. If you're looking for something with low lock-in that's still easy to manage, Buildkite is a great option. I'll warn you though: if you're going to do any kind of cloud hosting for your runners, and you want to build docker images, best to avoid their dockerized runners. Just install natively on a linux box, either manually, with an AMI, etc. Docker-in-Docker sucks; not impossible to get working, but not worth your time.
* Jenkins/JenkinsX. If you want something with zero lockin but also hard to manage.
* AWS CodeBuild/CodePipeline/CodeDeploy. There is, like, no one I feel comfortable recommending these options to, but people still use them because they're AWS.
> Gitlab CI. Good value, great integration with Gitlab, has integration with Github.
Yep. Now I'm thinking on migrating my AppImage build scripts (Travis CI + Transfer.sh used for my projects on GitHub) from Travis CI to Gitlab CI. Hope, that there is simple "3-step switch" option.
Really appreciate those FLOSS projects which already use "Gitlab repo + Gitlab CI" to build & provide builds/artifacts, e.g. GrafX2[0], Inkscape[1], etc.
I'm quite happily using a self-hosted Drone (drone.io) instance, though I don't have much experience to compare it with with other CI systems and my use case is probably not the most sophisticated one. Team is quite responsive, especially considering I'm a free tier user.
I really like Drone. The way “drone exec” works for local builds is really good. Hopefully getting bought by Harness doesn’t ruin it too much, but they already seem to be setting up to split it into versions/tiers.
Almost all current CI systems suck at building Docker containers :-(
One thing people forget about GitHub Actions is that you can self-host the runners for unlimited CI minutes (or custom hardware/os combos)! Just like on GitLab CI.
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.
The build agents are self-hosted. So it would work for the GP where they are open to hosted services but have their own compute that they might want to use.
Sourcehut is something you might want to look at. It's modular, so you use what you use, and ignore the rest.
The CI they offer makes no assumptions about where your repos might live (git is git. Who cares who the host is), and offers the stuff you might need like secrets, ssh keys, etc. The images they supply for testing actually seem more extensive than the other players.
And if you really want to self-host it... Go ahead. The whole of sourcehut is open source and reasonably well documented. You can host your own build server with minimal fuss.
Interesting, I didn't know it would support pulling from other git hosts. It looks like their CI even has an API integration with GitHub at least for PRs. That's looking like a potential winner. Thanks for pointing that out.
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 bit confusing), but I really don't want to admin it.
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.
I have been GitHub Actions ever since they released, but used to use TravisCI before that. There were one or two projects where I used CircleCI and it seemed more mature that TravisCI.
I always had insane amounts of queue time on gitlab's CI too. I know they have self-hostable runners, do you know if those work from behind a firewall so I could run them on hardware I have at home?
Also, do you know if it's possible to use gitlab CI as a merge gate on github PRs?
We had been paying ~$500/month for the open-source project (https://dvc.org) even before this new pricing model, and migrated to GitHub Actions recently- works like a charm. The only issue that we have now is Windows builds- machines on GH have a bit less resources, but it's good for us to optimize it anyway.
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.
This is why I use GitLab with self-hosted runners for all sorts of esoteric platforms, then use their linux runners for the basics. I don't like to freeload, so I do have a Bronze subscription which includes a certain number of monthly CI minutes for private projects, as mentioned here: https://about.gitlab.com/releases/2020/09/01/ci-minutes-upda.... But I rarely make use of it. Also note that there are special arrangements for Open Source projects.
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.
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 rent a VPS or Physical Server somewhere and spend a few hours setting up <insert ci tool of your choice).
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.
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.
Reading your post, I realized that I'm a company (albeit a very small one) that profits from your work and doesn't pay you.[0] I use your Nginx role in my open source product[1], and I use several of your other roles in my development environment. I just signed up as a monthly sponsor.
Thanks for your fantastic contributions to the Ansible ecosystem and to open source in general. Apologies for my past freeloading!
Ha, thanks so much! I'm trying (and having at least moderate success) to make it so I can devote half my weekly 'work' hours to pure OSS work, and the sponsorships are getting me close!
Then your are in a position similar to Travis until now: offering a lot of value for free. You need to find a way to monetize the project(s). Only one of all those companies need to give 100 bucks a month to pay for the CI + extras.
Travis 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.
> 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...
I think everyone should move from Travis CI, especially private repos. Idera bought the project that has no future, and it wants to get the money back. It won't get any better.
Idera has fired a lot of Travis CI engineers, and your private repositories are now at risk. They can save some extra money on security.
It seems to me if it takes you many hours to migrate your project from one CI provider to another you're doing things wrong.
Ultimately your .travis.yml file is a proprietary format for a service that you have no control over. You probably shouldn't have built your project's future on the assumption that it's always available.
Ideally you should have your own testing infrastructure in scripts or test frameworks. And your travis file shouldn't do much more than installing dependencies and running the stuff that's under your control. Put all the logic into the stuff you can control - and next time you find out that your favorite CI provider is no longer nice to you you simply use another one, the migration should not take more than a few minutes.
That's exactly how I have 95% of my travisfiles configured (15 or so lines to describe Travis config and install a couple deps, then '[testtool run]'. But I have over 200 projects to finish migrating.
What kind of monstrous CI process can take 4 weeks to migrate?
I know from experience that CI takes a lot of time, but even the very worse one that I have worked so far (dozens of parallel runs on different machines and a thousand lines of yaml) only took me 3 days to migrate.
Each one takes a few minutes (even with automation doing the lion's share of the groundwork). I have migrated around 130 repos so far, and have somewhere between 40-50 left. Some of the last ones actually used more of Travis CI's environment features, so they'll take longer to migrate.
Thanks for this pointer, Jeff. I just spent some time adding another test in travis-ci on one of my projects, and this HN post got me to go in and set up the Github actions and badge. Side effect: The test ran in 1 minute on Github where Travis-CI took ~20.
Have spent several days over the past few months working on a reimplementation of Nix support to make it possible to wind down "community" support without forcing projects to find a new CI.
One thing I will say - I like the way that you've done your migration. I'm very wary of using defined actions written by GitHub or otherwise, because it seems to me that it leads to vendor lock in for CI.
Ditto, plus it's hard to lock in versions for specific 3rd party actions and keep them updated. You either get 'latest' and hope the 3rd party is trustworthy, or you have to enter in SHAs.
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.
Travis is trash anyway. I've switched to CircleCI years ago and I'm happy with it. Also completely free. PS: I'm in no way affiliated with CircleCI, I'm just a happy customer.
I moved my open source repos to GitHub Actions from TravisCI after experiencing 6+ hour build queues. So far, GitHub Actions has been great and I love the Super Linter!
Get a cheap server and just self host drone. It’s been rock solid for me. Although I am using GitHub actions more, drone powers all of more heavy duty docker builds.
> I just spent the past 6 hours migrating some of my open source projects from Travis CI to GitHub Actions
Man. Sounds like my personal hell.
I’ll never understand how people motivate themselves to run projects. When I think about it I just envision doing a bunch of crap like that, dealing with issues people file, etc etc. No thank you.
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. No one wants to learn the custom setup steps, not even for the "biggest" of the bunch. (Is that still Github? Who knows? I don't.)
Oh, and if or when I migrate away from a CI system, like right now... Good thing I just kept it simple, you know?
Even for builds that target Windows, I just run a shell script.
I get it that Node and Rust builds really benefit from the advanced features. Anyone care to comment - is it as portable as a shell script?