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

Moving Away from Travis CI

ropensci.org

Post reply on HN
Print view View original

71–79 of 79 posts

Re: Moving Away from Travis CI

#71

Post by bluenose69 »

I moved to github actions (GHA) for an R package, and found these benefits of GHA over travisCI: 1. It's much faster. I think this is because it does not have to build up an environment from scratch, but instead caches some elements. 2. It is more reliable. Those early steps that travisCI takes in building up an environment seem to be error-prone, leading to failures long before it got around to checking my code. Usually, these were bad-signature or failure-to-download problems with basic libraries, and they tended to go away after a few days or a week, but in the meantime, my "badges" made it look as though my code had failed tests, when it was more that the tests were failing of their own accord.

And the disadvantages of the switch? None that I've noticed, so far. Perhaps the bloom will go off this rose as well, but that's life in the software world.

Re: Moving Away from Travis CI

#72

Post by Macha »

shakna wrote: post #65
xvilka wrote: post #59

Earlier quoted context omitted.

There are no checks in those - they are empty fields.

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).

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.

Re: Moving Away from Travis CI

#73

Post by saagarjha »

Spivak wrote: post #45
cube00 wrote: post #40

> The native integration with GitHub this takes away the annoying authentication dance that is required for third party services. We really need to improve the "annoying authentication" so this doesn't become a reason to continue building silos with a single vendor.

The issue is that this is one of those things that’s a direct trade-off between ease of use and security. The smoothest authentication is “this

Luckily, my CI platform supports "this authentication.

Re: Moving Away from Travis CI

#74

Post by jhasse »

rleigh wrote: post #67
jhasse wrote: post #62

Earlier quoted context omitted.

No free Windows and macOS runners.

It's easy enough to add your own. I use the cloud-based runners for Linux, then provide my own for Windows, Mac and FreeBSD, all VMs.

Maybe it's easy to add them, but I don't have any Windows or macOS servers in the first place.

Re: Moving Away from Travis CI

#75

Post by jhasse »

scrollaway wrote: post #70
rnestler wrote: post #61

Earlier quoted context omitted.

Why not move to GitLab right now? Their core product is OSS and the CI is integrated and free for OSS projects.

I don't really see how it's any better. But I am using and loving gitlab ci for my projects on paid plans fwiw.

It's better because you could move to self-hosting if something happens to gitlab.com.

Also other CI systems support their configuration format: https://blog.drone.io/drone-adapter-gitlab-pipelines/

Re: Moving Away from Travis CI

#76

Post by tpoacher »

(Paraphrasing) "Therefore, we find ourselves looking to other open-source friendly solutions, the greatest of which currently seems to be the one by Microsoft."

Honestly, we live in weird times.

Re: Moving Away from Travis CI

#77

Post by KronisLV »

mschuster91 wrote: post #22
jniedrauer wrote: post #17

Earlier quoted context omitted.

Chiming in to say: Avoid Jenkins like the plague. Jenkins is a bottomless pit of vulnerabilities and obscure bugs and outdated documentation that will waste weeks of your life. (Caveat: If you plan to do devops at a Big Corp, then you might as well get good at Jenkins because they already use it.)

Gitlab CI could almost replace Jenkins. I say almost because Gitlab CI lacks one critical thing: support for tasks independent of a commit or other event. Stuff like "take a dump of the production database and synchronize it to the integration environment". Also, Gitlab CI is, due to its nature of polling workers instead of the master pushing work to the slave as well as spinning up a new container for each job inste…

Here's an example of scheduling pipelines to execute automatically: https://docs.gitlab.com/ee/ci/pipelines/schedules.html

Here's an example for running pipelines manually (can even be triggered through the UI): https://docs.gitlab.com/ee/ci/yaml/#whenmanual

I believe the other comments address some of your other concerns as well.

Re: Moving Away from Travis CI

#78

Post by malinens »

KronisLV wrote: post #77
mschuster91 wrote: post #22

Earlier quoted context omitted.

Gitlab CI could almost replace Jenkins. I say almost because Gitlab CI lacks one critical thing: support for tasks independent of a commit or other event. Stuff like "take a dump of the production database and synchronize it to the integration environment". Also, Gitlab CI is, due to its nature of polling workers instead of the master pushing work to the slave as well as spinning up a new container for each job inste…

Here's an example of scheduling pipelines to execute automatically: https://docs.gitlab.com/ee/ci/pipelines/schedules.html Here's an example for running pipelines manually (can even be triggered through the UI): https://docs.gitlab.com/ee/ci/yaml/#whenmanual I believe the other comments address some of your other concerns as well.

manually running pipelines is much easier and more confifurable in jenkins. there are many issues which are created in gitlab so it is easier to migrate from jenkins but those issues are not prioritized
Post reply on HN