5 ms·

I'm surprised people are still using Travis CI. The writing was on the wall the day of the acquisition. I moved all of my builds immediately.

chrisseaton 6y ago
I work with an important open source project with large full-time professional and competent teams working on it... that had no idea .org as shutting down until a couple of weeks ago. Their messaging wasn't enough.
- stevekemp 6y ago
  The parent was perhaps a little pessimistic, but I admit the moment I heard there was an acquisition I too assumed that things would change, and I also preemptively started moving my stuff away from them. Happily I'd gotten into a habit of making sure my repositories were "self-contained" already, when I first started using self-hosted Travis (Hudson?) back in the day I did all the configuration in the UI, but soon realized I should keep the CI-system very simple and essentially run "make test", "make build", etc. Having the actual test/build scripts inside the repositories means that a human could easily run the same things interactively, and that moving between CI-systems is painless. All you need to do is configure the appropriate location of the repository and enter the names of the appropriate scripts. Even now my github actions assume that they can just run a script within the repository, for example the most basic one: https://github.com/skx/github-action-tester https://github.com/skx/github-action-tester
- koolba 6y ago
  I didn’t know till I read this blog post.
cortesoft 6y ago
My company was using it on 400+ repos, it isn't like we could just migrate the next day.
- philihp 6y ago
  I’ll bet/hope 80% of them were simple and static libraries without any mono-repo nonsense.
xvilka 6y ago
We (radareorg/radare2 team) use Travis CI specifically to build and run tests on ARM64 (ARMv8 or AArch64), PowerPC64, and SystemZ (s390)[1]. No other CI service offers those. I wish there were also MIPS, SPARC, and RISC-V. [1] https://travis-ci.com/github/radareorg/radare2/builds/202966063 https://travis-ci.com/github/radareorg/radare2/builds/202966...
- shakna 6y ago
  sr.ht supports ARM64, PowerPC, and SystemZ from what I can see on the list of supported builds: [0] They also support MIPS (and their BSD builds support SPARC). [0] https://man.sr.ht/builds.sr.ht/compatibility.md https://man.sr.ht/builds.sr.ht/compatibility.md
  - xvilka 6y ago
    There are no checks in those - they are empty fields.
    - shakna 6y ago
      The lack of a checkmark signifies that it runs virtually rather than on real hardware - which I believe is the same for TravisCI (SystemZ builds are atop AMD for example).
      - Macha 6y ago
        There's a supported box for "any support" and a native box for non-emulated support. There's also this statement: > Note: support for multi-arch builds is underway, but not yet available.
- dtech 6y ago
  If you have such niche needs I'd say you're better off with a self-managed Jenkins CI. afaik they support whatever you make available yourself.
pizza234 6y ago
Mving may require significant effort for products with sophisticated configurations. Also, while I don't imply either to move or to stay, Travis still does the job as it did before¹, so, unless pricing or specific features are a requirement, the technical incentive to move may (may) not be high enough. ¹=I did notice one change though, and it's that the list of the builds slowed down at some point; their solution: reduce the entries listed while loading (!!).

chrisseaton 6y ago

I work with an important open source project with large full-time professional and competent teams working on it... that had no idea .org as shutting down until a couple of weeks ago. Their messaging wasn't enough.

stevekemp 6y ago
The parent was perhaps a little pessimistic, but I admit the moment I heard there was an acquisition I too assumed that things would change, and I also preemptively started moving my stuff away from them. Happily I'd gotten into a habit of making sure my repositories were "self-contained" already, when I first started using self-hosted Travis (Hudson?) back in the day I did all the configuration in the UI, but soon realized I should keep the CI-system very simple and essentially run "make test", "make build", etc. Having the actual test/build scripts inside the repositories means that a human could easily run the same things interactively, and that moving between CI-systems is painless. All you need to do is configure the appropriate location of the repository and enter the names of the appropriate scripts. Even now my github actions assume that they can just run a script within the repository, for example the most basic one: https://github.com/skx/github-action-tester https://github.com/skx/github-action-tester
koolba 6y ago
I didn’t know till I read this blog post.

cortesoft 6y ago

My company was using it on 400+ repos, it isn't like we could just migrate the next day.

philihp 6y ago
I’ll bet/hope 80% of them were simple and static libraries without any mono-repo nonsense.

xvilka 6y ago

We (radareorg/radare2 team) use Travis CI specifically to build and run tests on ARM64 (ARMv8 or AArch64), PowerPC64, and SystemZ (s390)[1]. No other CI service offers those. I wish there were also MIPS, SPARC, and RISC-V. [1] https://travis-ci.com/github/radareorg/radare2/builds/202966063 https://travis-ci.com/github/radareorg/radare2/builds/202966...

shakna 6y ago
sr.ht supports ARM64, PowerPC, and SystemZ from what I can see on the list of supported builds: [0] They also support MIPS (and their BSD builds support SPARC). [0] https://man.sr.ht/builds.sr.ht/compatibility.md https://man.sr.ht/builds.sr.ht/compatibility.md
- xvilka 6y ago
  There are no checks in those - they are empty fields.
  - shakna 6y ago
    The lack of a checkmark signifies that it runs virtually rather than on real hardware - which I believe is the same for TravisCI (SystemZ builds are atop AMD for example).
    - Macha 6y ago
      There's a supported box for "any support" and a native box for non-emulated support. There's also this statement: > Note: support for multi-arch builds is underway, but not yet available.
dtech 6y ago
If you have such niche needs I'd say you're better off with a self-managed Jenkins CI. afaik they support whatever you make available yourself.

pizza234 6y ago

Mving may require significant effort for products with sophisticated configurations. Also, while I don't imply either to move or to stay, Travis still does the job as it did before¹, so, unless pricing or specific features are a requirement, the technical incentive to move may (may) not be high enough. ¹=I did notice one change though, and it's that the list of the builds slowed down at some point; their solution: reduce the entries listed while loading (!!).