I started using Travis initially because I needed a way to have consistent builds of our desktop software (built on Electron). Travis has just the tools I needed to make this happen. Doing local builds of the software was processor intensive, I had to go check the status of the build and I was always changing software on my local machine so sometimes builds would fail because I changed something. Travis has completely containerized build machines so you get the same result every time. We now use it for building all our software. I don't know what we'd do without it.

* Affordable (it's priced based on users/seats) * Documentation is solid and easy to follow. I've never needed to contact support. There's good online Q&A since Travis has a large user base. * Versatile (whatever software you're building, there's a recipe for it) * Github integration : you get realtime build status RIGHT in Github which is awesome, once you get your system set up, you rarely ever visit Travis again. It just works.

There's really nothing I didn't like about Travis. Some of the quirks of Electron were the trickiest things to figure out, but that's not Travis's fault. There's a little learning curve when you go from building locally to building remotely with Travis where you need to understand how to set environment variables and retrieve those values in your config/script.

I like how easy it is to deploy and get up and running with this software and configuration files, etc (e.g. it's essentially just a commandline which is nice). It was also really nice for all of my open-source projects while travis-ci.org was still running. I could deploy and have builds run without having to worry about money.

Ever since the move to travis-ci.com, support has been terrible and I've used up all of my free trial credits on my open-source web application's Cypress integration tests (https://github.com/tutorbookapp/tutorbook). I contacted support 5 days ago and still haven't heard back about getting more open-source credits for my account. I seriously miss travis-ci.org (though I completely understand the problems with cryptocurrency mining, etc).

Our initial years with Travis were successful, and we were quite happy with the product. But over time, the lack of flexibility meant struggling to create and deploy our CI definitions. But the part that killed Travis for us was the change to OSS terms late in 2020. We'd already noticed that our queues would become long, particularly if we had many contributors or maintainers working simultaneously. But with the changes in terms, we quickly ran into a scenario where we ran out of hours by mid-month. This left us with an untenable situation; as an OSS project, we have limited funds, and we would quickly run through those if we purchased a plan. As a result, we are within 1-2 weeks of moving off the platform entirely.

When we first started using the product, it was one of the few that existed, and it provided us exactly the assurances we needed to have predictable, stable software releases. Idempotent runs made it possible to know exactly when and why something failed.

Since we produce OSS libraries, it's important for us to test against each language version we support. Unfortunately, there is no way in Travis to dynamically create a matrix based on the library/package definition itself. For instance, we produce PHP libraries, and our package management solution, Composer, allows us to specify in the package the versions we support. Unfortunately, when we change those, we also need to remember to change the Travis definitions to reflect those changes. This becomes a source of error very quickly - Travis may report all is green, but it turns out we haven't added the new PHP version to the matrix, so it's a false sense of assurance. On top of that, it's impossible to succinctly make discrete jobs that do different things. For instance, I don't need to run coding standards checks, static analysis, and documentation linting for every single job in the matrix; I really only need to run these once. But to do that, Travis forces me to define env variables for jobs, and then use conditionals to determine what to run. This makes the CI definitions very convoluted, and, if you have a lot of repositories that need to do the same, hard to distribute when you have changes to make. Other CI systems address this.

I'm very happy about Travis, until now I found always an answer for each need I had

1. Documentation, maybe the most important value 2. Configuration flexibility in particular GIT SSH custom keys, env variables with sensitive information, build trigger (with inline configuration... very useful for testing configurations), machine SSH encrypted keys, configuration imports, custom scripts 3. Easy integration with GitHub

Permissions check (it's not so clear understand who can build, who can view build history, who can edit configuration).

I like that I can see the live status from GitHub and that the UI is very simple. I can easily find everything. The console output is colorized (it's not in other CI software I've used).

Sometimes parts of log output is collapsed, which has hidden an error for me before. It took a while, but my team figured it out.