loading...

Discussion

markdown guide
 

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

 

Yeah, CIs are very confusing. I gave up on publishing my project to PyPI using GitLab CI just because it was too hard. Having a Docker container with the environment locally eases the pain, since you can experiment with deployment pipeline and then construct a script which will work from the first time and won't fill up your repositories with countless "CI fix" commits.

 

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.