I had the "simple" goal of setting up automatic builds for my Go project. And it's been a nightmare.
https://github.com/nektro/andesite
https://travis-ci.org/nektro/andesite
The docs are hard to follow, the error messages aren't descriptive, and it has taken up most of my afternoon.
In other news, I switched from Windows to Debian on my main machine and I've been loving every second of it.
Top comments (8)
I feel your pain. I took the time to migrate a Travis CI configuration over to Buildkite. It was infinitely better! You have to host the CI server yourself, but you can control the resources and environment.
Any advice or gotchas to look out for when making the switch. I am thinking about taking the leap as Travis is just not featured enough for all the things we want to do.
It was over a year ago when I made that migration, and have since switched companies, but I don't recall anything that was glaringly difficult. I found the Buildkite documentation to be very well written. I found the Buildkite configuration to be drastically different, in that it allows for a more modular configuration compared to the Travis CI configuration. I was working on a Docker based project, so I found it very convenient that I could run my integration tests concurrently. Since Buildkite is self-hosted, I was able to ensure that my pipelines were always running consistently and fast.
That said, I do remember having to take some extra steps to ensure that my environment secrets were secure. Buildkite has a few methods, but I used agent hooks to achieve what I needed: buildkite.com/docs/pipelines/secre...
Best of luck! I hope it works for your use case! :)
Thanks for the insight!
At first glance, the BuildKite docs do look very well written which is always encouraging and from searching around, it seems like it might be a little more work to set up but a lot of people really like it.
Debugging with a lot of frameworks isn't stellar. Often, you need to figure out "how do I force things to be meaningfully verbose". Downside to that being that, in doing so, you can end up not using the tool the way it's meant to be used.
#Catch22
Indeed it is. My advice would be very cautious cache in your builds unless you absolutely need the time increase. Other things I've done is setup my own VM and run the commands which I'm in control of one by one. Lastly, sometimes I've seen travis-ci fail on dependencies at which point I just wait a day and try again. Patience is key if you are using their free tier.
Docker is good.
@maestromac , do you have similar feelings? π