6 ms·

Many people are saying to those of us who _haven't_, for one reason or another, gotten completely off of Travis CI, "the writing was on the wall" or "you can't

Many people are saying to those of us who _haven't_, for one reason or another, gotten completely off of Travis CI, "the writing was on the wall" or "you can't expect free forever." And I think they're missing the gravity of the situation—there were (and are still) a _ton_ of OSS projects out there that are configured to use Travis CI for their testing and build pipelines, and it's not free to switch to something else (even though there are many adequate alternatives). I wish there was another way, like providing a meager amount of build minutes, or just reducing the OSS builds to run on a few dozen servers, even if that means days-long build queues. That's better than just ending service abruptly like they did. I wrote [1] about my own plans, but I know many devs (especially for tiny side projects) just don't have the time to update them to something else, and we're likely to see a number of smaller projects kind of fall into disrepair from this. [1] https://www.jeffgeerling.com/blog/2020/travis-cis-new-pricing-plan-threw-wrench-my-open-source-works https://www.jeffgeerling.com/blog/2020/travis-cis-new-pricin...

znpy 6y ago
I honestly think this is the price that people pay for using proprietary software. The license terms changed and boom now you're out of service. If such OSS projects were running on Gitlab (either gitlab.com or selfhosted) then any of the members could have donated spare computing resources by running a gitlab runner on their prem. Many people have PCs running 24/7 and could spare a vm to lend to their favourite projects.
- koolba 6y ago
  Running arbitrary code on a distributed network of end user PCs with network access is a recipe for a bot net. Yes it’s doable but it’s not a magic wand to claim that an open platform will solve it. The magic of Travis was that with a couple clicks of OAuth you were signed up and running builds for your own PRs. My first thought upon seeing this years ago was “How many people are using this to mine crypto?!“.
  - znpy 6y ago
    > Running arbitrary code on a distributed network of end user PCs It's a bit more complicated than that. I run gitlab and gitlab runners for a living, I can tell. First thing first, you'd have to register a runner with a specific project. So no "arbitrary code". Second thing, unless you can push a branch to the project main repository, no pipeline is ran. So for your own personal forks you'd either rely on gitlab.com-provided free minutes or you run your own runner (and tbh, it's fairly easy). Last thing: you should not think of regular end-users. Think of middle to advanced users, that have a home server or something like that (homelabbers?).
    - nl 6y ago
      > First thing first, you'd have to register a runner with a specific project. So no "arbitrary code". This isn't what "arbitrary code" means.
  - eins1234 6y ago
    > My first thought upon seeing this years ago was “How many people are using this to mine crypto?!“. Having worked at a Travis CI competitor that also offered open-source credits. The answer is "many" if you don't do anything about it...
    - floatboth 6y ago
      What is the state of the art in doing something about this? Has anyone tried using CPU perf counters to see if the workload looks like hashing?
    - jrochkind1 6y ago
      Indeed, that is why Travis said they were changing the way they handled open source, because people were using it to mine crypto. They just weren't clear that the "change" was basically "not anymore providing free services to open source".
  - josteink 6y ago
    > The magic of Travis was that with a couple clicks of OAuth you were signed up and running builds for your own PRs. With GitHub Actions it's even simpler, and no OAuth required at all. I especially like the auto-suggested template-types based on what kind of project the repo hosts (Node, Python, etc).
- nuritzi 6y ago
  Saw the note about GitLab (I work there) and thought I'd chime in. For those who don't know, we have a GitLab for Open Source program which gives our top tiers and 50K CI minutes/month for free to OSS projects: https://about.gitlab.com/solutions/open-source/ https://about.gitlab.com/solutions/open-source/ Hope this helps!
  - znpy 6y ago
    Thanks for chiming in! I like gitlab so much I couldn't miss this opportunity to recommend it. The nice thing about Gitlab is that you can mix on-prem and saas according to your need. For example I am now running my own gitlab instance at home but I'm thinking of switching to the gitlab.com offering while keeping runners at home. By pairing gitlab with Hashicorp Vault I could keep encrypted stuff in my repo and decrypt them when they are checked out on the (local on-prem) runner. Super cool, so much flexibility!
jrochkind1 6y ago
When this was posted to HN a month ago [1] is actually when I learned it was going on -- I sure wouldn't have figured it out from travis' communications, even to this day. Up until my projects simply stopped building at all I guess. Since then I have switched a bunch of projects over to Github Actions, fortunately they were all relatively simple enough to make that straightforward. [1] https://news.ycombinator.com/item?id=25003387 https://news.ycombinator.com/item?id=25003387
floatingatoll 6y ago
Are there GitHub CI integrations that offer payment integration, so that the submitter of the pull request can be charged for the costs of CI related to their pull request?
- claytonjy 6y ago
  what kind of project would you use this in? I can see how this might combat a very specific type of abuse, but it seems like it'd be even more effective in deterring contributions entirely.
  - floatingatoll 6y ago
    Any project where I as project operator cannot afford CI credits for the hundreds of pull requests people submit to me while presuming I can afford to provide them CI.
    - gilbertbw 6y ago
      GitHub actions are free for open source projects
    - jrochkind1 6y ago
      I think the number of people that would choose to pay for a PR to your project is small enough that you could probably just do it manually, and ask them to venmo/paypal/cashapp you money. You are probably not going to get very many.
smarx007 6y ago
Ah, Jeff, actually thanks to your post I saw that most of the projects I contribute to had Travis CI builds take almost a day and I went over most of those that used free TravisCI/CircleCI/Semaphore and started migrating them all to Github Actions. So again, thank you for your particular inscription on the blog, I guess.
- smarx007 6y ago
  Another point: is there an open spec for GH Actions, that Gitlab could implement? Or vice versa, could Github support Gitlab CI? I am thinking of CI these days as some kind of wild west as back in the days before a common Open Container Initiative spec...
  - wwright 6y ago
    There’s Tekton?
  - darekkay 6y ago
    I don't think something like this will happen, because GitHub Actions and GitLab CI work quite differently. But maybe there will be a migration tool from one to the other.
josteink 6y ago
> And I think they're missing the gravity of the situation—there were (and are still) a _ton_ of OSS projects out there that are configured to use Travis CI for their testing and build pipelines, and it's not free to switch to something else (even though there are many adequate alternatives). There's obviously a cost associated with this, but after started reading this thread, I just ported 10+ of my GitHub project from Travis-CI to GitHub Actions. Unless your project has very specific/weird build requirements (in which case it should not be part of .travis.yml, but in a separate, reusable build-script), it was really surprisingly simple to make the switch. I've ported Emacs, NodeJS and Python projects with ease. Having had many of my project built using makefiles, running that makefile somewhere else was no big deal at all. If anything, if making the switch now is hard work, you should use that effort into making your build more portable. You may thank yourselves 5-10 years down the road when this same thing surely is bound to happen again :)
qchris 6y ago
I help out as a maintainer for an open source machine learning group, and first learned about the switch in Travis CI's policy from your blog. Not too long after, the projects the groups repository owns all got switched over to Github Actions. I know that especially for folks that have many smaller projects, there's a lot of overhead in switching, but I really did appreciate your alerting people to the upcoming change through a different venue, as I'm sure it saved us some pain.
blihp 6y ago
Because people absolutely refuse to learn from history. The gravity of the situation is the same as it always is: OSS projects have created a hard dependency on a commercial 3rd party service because it was given to them for free. Free service is now going away and they're screwed because they have no plan 'B'. The issue isn't that they haven't gotten off of it already, it's that they likely never should have gotten on it to begin with. Seriously, with all the OSS projects building workflows on Travis CI / Slack / GitHub (I'm talking about the non-git parts of it like issue management) / etc how do they think this will all end? Even YouTube is sending signals that the free ride (for unmonetizable content) will likely end. OSS projects should not have dependencies on non-OSS infrastructure unless they are prepared for this eventuality. This has happened, in various forms, to most 'free as in beer' services given enough time. Companies typically provide the service as some combination of crush the competition / building goodwill / altruism / the prospect of eventual conversion of some small fraction of OSS projects to a paid version. The reasons tend to vary (in this case, new ownership) but eventually the bottom line tends to win out. Often you won't be given much time to transition when the free ride ends.
- progval 6y ago
  > OSS projects should not have dependencies on non-OSS infrastructure unless they are prepared for this eventuality. I don't think that's the issue. Large parts of Travis are open sourc, but no one uses it because they are too complex to set up; and there are better self-hosted solutions than Travis. Travis was attractive, because it was free hosting, not just software. And worked with just a few clicks
  - outsomnia 6y ago
    If it's not selfhosted, or it's not FOSS, it's not under your control and can go away any time. It's certainly easy to get into these lassaiz-faire ad-hoc remote free solutions, it's harder to maintain your own CI, but if quality and consistency is important, it's not that hard.
- takluyver 6y ago
  What was the better option? Should small OSS projects have lived without CI for the last few years? Or should everyone who publishes an OSS project set up and maintain a self-hosted CI service for it? Either option would be a massive drag on OSS development. It doesn't actually matter much for this if you use an OSS CI service like Gitlab: the hosted service is still dependent on the generosity/marketing of the company hosting it, and switching to self-hosting is much more effort than porting config from one CI service to another.
miohtama 6y ago
> there were (and are still) a _ton_ of OSS projects out there that are configured to use Travis CI for their testing and build pipelines, and it's not free to switch to something else (even though there are many adequate alternatives). Github Actions is free. I migrated some repos to Github Actions this year and the process is relatively painless. Also I do not expect Microsoft to turn off Github Actions for OSS projects as long as you stay within your rate limited budget.
- jrochkind1 6y ago
  What "rate limited budget"? As far as I could tell there were no limits to Github Actions open source free?
  - miohtama 6y ago
    You are correct and I was wrong. At the moment it applies to private repositories only.

znpy 6y ago

I honestly think this is the price that people pay for using proprietary software. The license terms changed and boom now you're out of service. If such OSS projects were running on Gitlab (either gitlab.com or selfhosted) then any of the members could have donated spare computing resources by running a gitlab runner on their prem. Many people have PCs running 24/7 and could spare a vm to lend to their favourite projects.

koolba 6y ago
Running arbitrary code on a distributed network of end user PCs with network access is a recipe for a bot net. Yes it’s doable but it’s not a magic wand to claim that an open platform will solve it. The magic of Travis was that with a couple clicks of OAuth you were signed up and running builds for your own PRs. My first thought upon seeing this years ago was “How many people are using this to mine crypto?!“.
- znpy 6y ago
  > Running arbitrary code on a distributed network of end user PCs It's a bit more complicated than that. I run gitlab and gitlab runners for a living, I can tell. First thing first, you'd have to register a runner with a specific project. So no "arbitrary code". Second thing, unless you can push a branch to the project main repository, no pipeline is ran. So for your own personal forks you'd either rely on gitlab.com-provided free minutes or you run your own runner (and tbh, it's fairly easy). Last thing: you should not think of regular end-users. Think of middle to advanced users, that have a home server or something like that (homelabbers?).
  - nl 6y ago
    > First thing first, you'd have to register a runner with a specific project. So no "arbitrary code". This isn't what "arbitrary code" means.
- eins1234 6y ago
  > My first thought upon seeing this years ago was “How many people are using this to mine crypto?!“. Having worked at a Travis CI competitor that also offered open-source credits. The answer is "many" if you don't do anything about it...
  - floatboth 6y ago
    What is the state of the art in doing something about this? Has anyone tried using CPU perf counters to see if the workload looks like hashing?
  - jrochkind1 6y ago
    Indeed, that is why Travis said they were changing the way they handled open source, because people were using it to mine crypto. They just weren't clear that the "change" was basically "not anymore providing free services to open source".
- josteink 6y ago
  > The magic of Travis was that with a couple clicks of OAuth you were signed up and running builds for your own PRs. With GitHub Actions it's even simpler, and no OAuth required at all. I especially like the auto-suggested template-types based on what kind of project the repo hosts (Node, Python, etc).
nuritzi 6y ago
Saw the note about GitLab (I work there) and thought I'd chime in. For those who don't know, we have a GitLab for Open Source program which gives our top tiers and 50K CI minutes/month for free to OSS projects: https://about.gitlab.com/solutions/open-source/ https://about.gitlab.com/solutions/open-source/ Hope this helps!
- znpy 6y ago
  Thanks for chiming in! I like gitlab so much I couldn't miss this opportunity to recommend it. The nice thing about Gitlab is that you can mix on-prem and saas according to your need. For example I am now running my own gitlab instance at home but I'm thinking of switching to the gitlab.com offering while keeping runners at home. By pairing gitlab with Hashicorp Vault I could keep encrypted stuff in my repo and decrypt them when they are checked out on the (local on-prem) runner. Super cool, so much flexibility!

jrochkind1 6y ago

When this was posted to HN a month ago [1] is actually when I learned it was going on -- I sure wouldn't have figured it out from travis' communications, even to this day. Up until my projects simply stopped building at all I guess. Since then I have switched a bunch of projects over to Github Actions, fortunately they were all relatively simple enough to make that straightforward. [1] https://news.ycombinator.com/item?id=25003387 https://news.ycombinator.com/item?id=25003387

floatingatoll 6y ago

Are there GitHub CI integrations that offer payment integration, so that the submitter of the pull request can be charged for the costs of CI related to their pull request?

claytonjy 6y ago
what kind of project would you use this in? I can see how this might combat a very specific type of abuse, but it seems like it'd be even more effective in deterring contributions entirely.
- floatingatoll 6y ago
  Any project where I as project operator cannot afford CI credits for the hundreds of pull requests people submit to me while presuming I can afford to provide them CI.
  - gilbertbw 6y ago
    GitHub actions are free for open source projects
  - jrochkind1 6y ago
    I think the number of people that would choose to pay for a PR to your project is small enough that you could probably just do it manually, and ask them to venmo/paypal/cashapp you money. You are probably not going to get very many.

smarx007 6y ago

Ah, Jeff, actually thanks to your post I saw that most of the projects I contribute to had Travis CI builds take almost a day and I went over most of those that used free TravisCI/CircleCI/Semaphore and started migrating them all to Github Actions. So again, thank you for your particular inscription on the blog, I guess.

smarx007 6y ago
Another point: is there an open spec for GH Actions, that Gitlab could implement? Or vice versa, could Github support Gitlab CI? I am thinking of CI these days as some kind of wild west as back in the days before a common Open Container Initiative spec...
- wwright 6y ago
  There’s Tekton?
- darekkay 6y ago
  I don't think something like this will happen, because GitHub Actions and GitLab CI work quite differently. But maybe there will be a migration tool from one to the other.

josteink 6y ago

> And I think they're missing the gravity of the situation—there were (and are still) a _ton_ of OSS projects out there that are configured to use Travis CI for their testing and build pipelines, and it's not free to switch to something else (even though there are many adequate alternatives). There's obviously a cost associated with this, but after started reading this thread, I just ported 10+ of my GitHub project from Travis-CI to GitHub Actions. Unless your project has very specific/weird build requirements (in which case it should not be part of .travis.yml, but in a separate, reusable build-script), it was really surprisingly simple to make the switch. I've ported Emacs, NodeJS and Python projects with ease. Having had many of my project built using makefiles, running that makefile somewhere else was no big deal at all. If anything, if making the switch now is hard work, you should use that effort into making your build more portable. You may thank yourselves 5-10 years down the road when this same thing surely is bound to happen again :)

qchris 6y ago

I help out as a maintainer for an open source machine learning group, and first learned about the switch in Travis CI's policy from your blog. Not too long after, the projects the groups repository owns all got switched over to Github Actions. I know that especially for folks that have many smaller projects, there's a lot of overhead in switching, but I really did appreciate your alerting people to the upcoming change through a different venue, as I'm sure it saved us some pain.

blihp 6y ago

Because people absolutely refuse to learn from history. The gravity of the situation is the same as it always is: OSS projects have created a hard dependency on a commercial 3rd party service because it was given to them for free. Free service is now going away and they're screwed because they have no plan 'B'. The issue isn't that they haven't gotten off of it already, it's that they likely never should have gotten on it to begin with. Seriously, with all the OSS projects building workflows on Travis CI / Slack / GitHub (I'm talking about the non-git parts of it like issue management) / etc how do they think this will all end? Even YouTube is sending signals that the free ride (for unmonetizable content) will likely end. OSS projects should not have dependencies on non-OSS infrastructure unless they are prepared for this eventuality. This has happened, in various forms, to most 'free as in beer' services given enough time. Companies typically provide the service as some combination of crush the competition / building goodwill / altruism / the prospect of eventual conversion of some small fraction of OSS projects to a paid version. The reasons tend to vary (in this case, new ownership) but eventually the bottom line tends to win out. Often you won't be given much time to transition when the free ride ends.

progval 6y ago
> OSS projects should not have dependencies on non-OSS infrastructure unless they are prepared for this eventuality. I don't think that's the issue. Large parts of Travis are open sourc, but no one uses it because they are too complex to set up; and there are better self-hosted solutions than Travis. Travis was attractive, because it was free hosting, not just software. And worked with just a few clicks
- outsomnia 6y ago
  If it's not selfhosted, or it's not FOSS, it's not under your control and can go away any time. It's certainly easy to get into these lassaiz-faire ad-hoc remote free solutions, it's harder to maintain your own CI, but if quality and consistency is important, it's not that hard.
takluyver 6y ago
What was the better option? Should small OSS projects have lived without CI for the last few years? Or should everyone who publishes an OSS project set up and maintain a self-hosted CI service for it? Either option would be a massive drag on OSS development. It doesn't actually matter much for this if you use an OSS CI service like Gitlab: the hosted service is still dependent on the generosity/marketing of the company hosting it, and switching to self-hosting is much more effort than porting config from one CI service to another.

miohtama 6y ago

> there were (and are still) a _ton_ of OSS projects out there that are configured to use Travis CI for their testing and build pipelines, and it's not free to switch to something else (even though there are many adequate alternatives). Github Actions is free. I migrated some repos to Github Actions this year and the process is relatively painless. Also I do not expect Microsoft to turn off Github Actions for OSS projects as long as you stay within your rate limited budget.

jrochkind1 6y ago
What "rate limited budget"? As far as I could tell there were no limits to Github Actions open source free?
- miohtama 6y ago
  You are correct and I was wrong. At the moment it applies to private repositories only.